Apparatus, Method and System For Directory Quality Assurance

ABSTRACT

An apparatus, method and system to validate the integrity of a persistent identifier of information that may be located in multiple locations, formats, and accessible in variable fashions based on the context of use ( 135 ). The present disclosure further provides the ability to validate that the information being identified is valid for any given identifier. The present disclosure also teaches the ability to automatically generate tags that allows for the validation of both information and associated information identifiers either through validation and/or through registration. The invention teaches how to test and assure the quality of association between an identifier of information and the actual information. The invention details how to automatically correct poor quality references being used by identifiers, and/or provides notification escalation to aid in maintaining persistent identifier and information association ( 135 ).

RELATED APPLICATIONS

The instant application hereby claims priority to the following U.S.provisional patent applications: (1) Ser. No. 60/264,333 for “ReferenceLinking with DOIs” filed on Jan. 25, 2001 (attorney docket number4188-4001); (2) Ser. No. 60/268,766 for “Apparatus, Method, and Systemfor Multiple Resolution Affecting Information Access” filed on Feb. 14,2001 (attorney docket number 4188-4002); (3) Ser. No. 60/276,459 for“Apparatus, Method, and System for Registration Effecting InformationAccess” filed on Mar. 16, 2001 (attorney docket number 4188-4003); (4)Ser. No. 60/279,792 for “Apparatus, Method and System For DirectoryQuality Assurance” filed on Mar. 29, 2001 (attorney docket number4188-4004); (5) Ser. No. 60/303,768 for “Apparatus, Method, and Systemfor Accessing Digital Rights Management Information” filed on Jul. 10,2001 (attorney docket number 4188-4005); (6) Ser. No. 60/328,275 for“Apparatus, Method and System For Accessing Digital Rights ManagementInformation” filed on Oct. 9, 2001 (attorney docket number4188-4005US1); (7) Ser. No. 60/267,875 for “Apparatus, Method, andSystem for Accessing Information” filed on Feb. 8, 2001 (attorney docketnumber 4188-4006); (8) Ser. No. 60/267,899 for “Provisional filing forApparatus, Method, and System for Accessing Information” filed on Feb.9, 2001 (attorney docket number 4188-4007); (9) Ser. No. 60/270,473 for“Business Value and Implementation Considerations For The DOI” filed onFeb. 21, 2001 (attorney docket number 4188-4008); (10) Ser. No.60/328,274 for “Apparatus, Method And System For Effecting InformationAccess In A Peer Environment” filed on Oct. 9, 2001 (attorney docketnumber 4188-4010); (11) Ser. No. 60/328,270 for “Apparatus, Method andSystem For Tracking Information Access” filed on Oct. 9, 2001 (attorneydocket number 4188-4011); each of these applications being hereinincorporated by reference.

The instant application, also, hereby incorporates by reference thefollowing Patent Cooperation Treaty applications: (12) for an“Apparatus, Method and System For Multiple Resolution AffectingInformation Access” (attorney docket number 4188-4002PC), which wasfiled on Jan. 25, 2002 in the name of David Sidman; (13) for an“Apparatus, Method and System For Registration Effecting InformationAccess” (attorney docket number 4188-4003PC), which was filed on Jan.25, 2002 in the name of David Sidman; (14) Apparatus, Method and SystemFor Accessing Digital Rights Management Information” (attorney docketnumber 4188-4005PC1), which was filed on Jan. 25, 2002 in the name ofDavid Sidman; (15) for an “Apparatus, Method and System For EffectingInformation Access in a Peer Environment,” (attorney docket number4188-4010PC), which was filed on Jan. 25, 2002 in the name of DavidSidman; and (16) for an “Apparatus, Method and System For TrackingInformation Access,” (attorney docket number 4188-4011PC), which wasfiled on Jan. 25, 2002 in the name of David Sidman.

FIELD

The present invention relates generally to an apparatus, method andsystem to validate the access of information across a communicationsnetwork. More particularly, the disclosed invention relates to anapparatus, method and system to verify the ability to access and resolvepersistent identifiers with their associated information in variouscontexts of use on a communications network.

BACKGROUND Internet

As Internet usage increases, the amount of information available on theInternet also increases. The information that exists on the Internet isof many different types, including documents in many formats such as:computer software, databases, discussion lists, electronic journals,library catalogues, online information services, mailing lists, newsgroups, streaming media, and the like. Fortunately, much of theinformation on the Internet can be accessed through the World-Wide Webusing a web browser to interact with the network in a user-friendly way.

Networks

Networks are commonly thought to consist of the interconnection andinteroperation of clients, servers, and intermediary nodes in a graphtopology. It should be noted that the term “server” as used hereinrefers generally to a computer, other device, software, or combinationthereof that processes and responds to the requests of remote usersacross a communications network. Servers serve their information torequesting “clients.” A computer, other device, software, or combinationthereof that facilitates, processes information and requests, and/orfurthers the passage of information from a source user to a destinationuser is commonly referred to as a “node.” Networks are generally thoughtto facilitate the transfer of information from source points todestinations.

Transmission Control Protocol-Internet Protocol (TCP/IP)

The proliferation and expansion of computer systems, databases, andnetworks of computers has been facilitated by an interconnection of suchsystems and networks in an extraterritorial communications networkcommonly referred to as the Internet. The Internet has developed andlargely employs the Transmission Control Protocol-Internet Protocol(TCP/IP). TCP/IP was developed by a Department of Defense (DoD) researchproject to interconnect networks made by various and varying networkvendors as a foundation for a network of networks; i.e., the Internet.The development of TCP/IP was in part driven by a requirement by the DoDto have a network that will continue to operate even if damaged duringbattle, thus allowing for information to be routed around damagedportions of the communications network to destination addresses. Ofcourse, if the source or destination address location itself is renderedinoperable, such delivery will not be possible.

The Internet is a packet-switched network and thus, information on theInternet is broken up into pieces, called packets, and transmitted inpacket form. The packets contain IP addressing information calledheaders, which are used by routers to facilitate the delivery of thepackets from a source to a destination across intermediary nodes on theInternet. Upon arrival at the destination, the packets are reassembledto form the original message, and any missing packets are requestedagain.

The IP component of the protocol is responsible for routing packets ofinformation based on a four byte addressing mechanism; the address iswritten as four numbers separated by dots, each number ranging from 0 to255, e.g., “123.255.0.123”. IP addresses are assigned by Internetauthorities and registration agencies, and are unique.

The TCP portion of the protocol is used for verifying that packets ofinformation are correctly received by the destination computer from thesource, and if not, to retransmit corrupt packets. Other transmissioncontrol protocols are also commonly used that do not guarantee delivery,such as User Datagram Protocol (UDP).

World Wide Web

The proliferation and expansion of the Internet, and particularly theWorld Wide Web (the web), have resulted in a vast and diverse collectionof information. Various user interfaces that facilitate the interactionof users with information technology systems (i.e., people usingcomputers) are currently in use. An information navigation interfacecalled WorldWideWeb.app (the web) was developed in late 1990.Subsequently, information navigation interfaces such as web browsershave become widely available on almost every computer operating systemplatform.

Generally, the web is the manifestation and result of a synergeticinteroperation between user interfaces (e.g., web browsers), servers,distributed information, protocols, and specifications. Web browserswere designed to facilitate navigation and access to information, whileinformation servers were designed to facilitate provision ofinformation. Typically, web browsers and information servers aredisposed in communication with one another through a communicationsnetwork. Information Servers function to serve information to users thattypically access the information by way of web browsers. As such,information servers typically provide information to users employing webbrowsers for navigating and accessing information on the web.Microsoft's Internet Explorer and Netscape Navigator are examples of webbrowsers. In addition, navigation user interface devices such as WebTVhave also been implemented to facilitate web navigation. Microsoft'sInformation Server and Apache are examples of information servers.

Universal Resource Locator (URL)

The expansion of the web has resulted in an enormous quantity ofinformation, which is accessible through the use of Universal ResourceLocators (URLs). An URL is an address that is typically embodied as ahyperlink in a web page or is typed into a web browser. URLs for a givenresource (most commonly a file located on a remote computer) refer onlyto a location for that resource. Typically, the reference to thelocation is achieved through the use of an unresolved IP address inconjunction with a directory path and file name; e.g.,“http://www.aWebSite.com/aFolder/aFile.html”. In this example, the URLdirects the browser to connect to the computer named “www” in the domain“aWebSite.com,” and to request the file named “aFile.html” stored indirectory “aFolder” at that computer.

Universal Name Identifier (UNI)

The Corporation for National Research Initiatives has created andimplemented a new means of naming and locating information, called theHandle System. The Handle System is designed to improve upon the currentuse of URLs.

The Handle System introduces a level of indirection to locating anddistributing information over the Internet. The Handle System is ageneral-purpose system for naming resources. Instead of being assigned aURL based on a particular resource's current network location, aresource may be assigned a Universal Name Identifier. A UNI is a form ofUniversal Resource Identifier (URI). URIs include both UNIs and URLs. AUNI, unlike a URL, serves and shall be regarded henceforth as a name forthe resource that is persistent regardless of changes in the resource'slocation or other attributes. In turn, a Universal Resource Name (URN)is a type of UNI (i.e., a UNI subsumes the concept of a URN).Furthermore, a Handle is a type of URN. And a Digital Object Identifier(DOI) is a type of Handle. Thus, various forms of UNIs include Handles,URNs, DOIs, and/or the like. The various terms and/or forms of UNIs willbe used interchangeably throughout this document, and may be assumed tobe interchangeable unless stated otherwise. A Handle is a unique name,which is registered with the Handle System along with the currentnetwork location of the named resource. This location informationcommonly takes the form of a URL. One common type of Handle is known asa Digital Object Identifier (DOI). Handles may be then distributed tousers in lieu of a URL, and superficially appear to function similarlyto a hyperlink. When a user encounters a Handle, the user may select orenter the Handle much like a URL hyperlink, so long as the user's webbrowser is capable of making Handle requests. Such an encounter triggersan automated process to look up a resource's current location. Thecurrent location of the resource is associated with the resource'sHandle in a directory made available by the Handle System, which in turndirects the user to the resource's current location. Unlike with a URL,if the resource moves, the Handle System directory entry can be updated,thereby assuring a persistent association between a Handle and theresource it identifies. An analogy can be made to the physical world:knowing only a URL for a given resource is akin to knowing only aperson's street address, and not her name. If she were to move acrosstown, it would be very difficult to locate her without knowing her name.The Handle System allows resources to be permanently named by way of aHandle, and it allows the current network location of resources to belooked up based on that name in a Handle System directory.

SUMMARY

Digital Object Identifiers overcome many of the shortcomings of IP- andother location-based addressing schemes. DOIs enable access toinformation over a communications network by providing a persistentidentifier for information that may be regularly relocated. DOIsovercome the limitations of network addressing schemes limited toaddressing locations by providing a mechanism to associate identifierswith information through an added level of indirection instead ofassociating identifiers with locations

Although DOIs provide a mechanism that allows for the association of anidentifier with information instead of a location, DOIs in and ofthemselves do not provide for the access of multiple and/or varyinginstances of a piece of information in various locations, formats, orthe access of various services associated with a given piece ofinformation, based on various contexts of use. Furthermore, until thepresent invention, there was no mechanism to validate that suchidentifiers, e.g., DOIs, would properly resolve a request to anappropriate piece of associated information.

In one embodiment, the disclosure teaches a method of using a computerfor validation, comprising: obtaining a unique, persistent, anduniversal name identifier for a source, obtaining location addresses ofthe source for resolution with the unique, persistent, and universalname identifier, and validating that the location addresses areaccessible.

In another embodiment, the disclosure teaches a method of using acomputer for validation, comprising: determining a tagging code, whereinthe tagging code, once recognized, establishes the validity of a source,and tagging a source with the tagging code, wherein the source isresolved to by a unique, persistent, and universal name identifier.

In another embodiment, the disclosure teaches a method of using acomputer to access information, comprising: determining a tagging code,wherein the tagging code, once recognized, establishes the validity of asource; tagging a source with the tagging code; generating a unique,persistent, and universal name identifier associated with the source;receiving an address for a location for the source; and effecting theregistration of the unique, persistent, and universal name identifierwith the address associated to the location of the source in a databasefor resolving unique, persistent, and universal name identifiers andlocations of associated sources, wherein the unique, persistent, anduniversal name identifier is unique in the database.

In another embodiment, the disclosure teaches a method of using acomputer to access information, comprising: determining a tagging code,wherein the tagging code, once recognized, establishes the validity of asource; tagging a source with the tagging code; allocating space in astorage facility for the source; making a location of the allocatedspace addressable and accessible over a communications network; storingthe source to the allocated space; generating a unique, persistent, anduniversal name identifier associated with the source; and effecting theregistration of the unique, persistent, and universal name identifierwith an address associated to the location where the source is stored ina database for resolving unique, persistent, and universal nameidentifiers and locations of associated sources, wherein the unique,persistent, and universal name identifier is unique in the database Theabove advantages and features are of representative embodiments only,and are not exhaustive and/or exclusive. They are presented only toassist in understanding the invention. It should be understood that theyare not representative of all the inventions defined by the claims, tobe considered limitations on the invention as defined by the claims, orlimitations on equivalents to the claims. For instance, some of theseadvantages may be mutually contradictory, in that they cannot besimultaneously present in a single embodiment. Similarly, someadvantages are applicable to one aspect of the invention, andinapplicable to others. Furthermore, certain aspects of the claimedinvention have not been discussed herein. However, no inference shouldbe drawn regarding those discussed herein relative to those notdiscussed herein other than for purposes of space and reducingrepetition. Thus, this summary of features and advantages should not beconsidered dispositive in determining equivalence. Additional featuresand advantages of the invention will become apparent in the followingdescription, from the drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate certain embodiments of thedisclosure.

FIG. 1 illustrates one example embodiment incorporated into a DirectoryQuality Assurance Server (DQAS) controller;

FIGS. 2 and 3 illustrate URL addressing across a communications networkwith moving information;

FIG. 4 illustrates accessing of information through DOIs;

FIGS. 5 and 6 provide an overview of a Handle;

FIGS. 7 and 8 provide an overview of the resolution mechanism forallowing users to access desired information;

FIG. 9 provides an overview of an exemplary sequence of actions that auser performs to access information using DOIs;

FIG. 10 provides a more complete overview of an exemplary sequence ofactions that users perform to access content information;

FIG. 11 illustrates an exemplary mechanism for accessing informationover a communications network;

FIG. 12 provides an overview of another embodiment of exemplarymechanisms for retrieving information over a communications network;

FIG. 13 provides an overview of an exemplary DOI system;

FIG. 14 illustrates one non-limiting example of the Directory QualityAssurance Server (DQAS) interacting with various entities;

FIGS. 15 and 16 illustrate non-limiting examples of the DQAS interactingwith various entities;

FIG. 17 illustrates a non-limiting example of the DQAS interacting withvarious entities in the validation of a Handle;

FIG. 18 illustrates a non-limiting example overview of a feeder and dataflow;

FIG. 19 illustrates one non-limiting example flow diagram of a qualityassurance UNI data miner facility (miner);

FIG. 20 illustrates one non-limiting example flow diagram of a qualityassurance enqueue feeder (NQ feeder);

FIG. 21 illustrates one non-limiting example flow diagram of a qualityassurance dequeue feeder (DQ feeder);

FIG. 22 illustrates one non-limiting example flow diagram of a directoryquality assurance pinger facility (pinger);

FIG. 23 illustrates one non-limiting example flow diagram of a qualityassurance error processor (error processor);

FIG. 24 illustrates one non-limiting example flow diagram of a qualityassurance error report policy (policy);

FIG. 25 illustrates a non-limiting example of a policy manager tool.

DETAILED DESCRIPTION Directory Quality Assurance Server Controller

FIG. 1 illustrates one example embodiment incorporated into a DirectoryQuality Assurance Server (DQAS) controller 101. In this embodiment, theDQAS controller 101 may serve to register, resolve, process, store,update, and validate Handles and any associated information, and/or thelike.

In one embodiment, the DQAS controller 101 may be connected to and/orcommunicate with entities such as, but not limited to: one or more usersfrom user input devices 111; peripheral devices 112; and/or acommunications network 113. The DQAS controller may even be connected toand/or communicate with a cryptographic processor device 128.

A typical DQAS controller 101 may be based on common computer systemsthat may comprise, but are not limited to, components such as: acomputer systemization 102 connected to memory 129.

Computer Systemization

A computer systemization 102 may comprise a clock 130, centralprocessing unit (CPU) 103, a read only memory (ROM), a random accessmemory (RAM), and/or an interface bus 107, and conventionally, althoughnot necessarily, are all interconnected and/or communicating through asystem bus 104. The system clock typically has a crystal oscillator andprovides a base signal. The clock is typically coupled to the system busand various means that will increase or decrease the base operatingfrequency for other components interconnected in the computersystemization. The clock and various components in a computersystemization drive signals embodying information throughout the system.Such transmission and reception of signals embodying informationthroughout a computer systemization may be commonly referred to ascommunications. These communicative signals may further be transmitted,received, and the cause of return and/or reply signal communicationsbeyond the instant computer systemization to: communications networks,input devices, other computer systemizations, peripheral devices, and/orthe like. Optionally, a cryptographic processor 126 may similarly beconnected to the system bus. Of course, any of the above components maybe connected directly to one another, connected to the CPU, and/ororganized in numerous variations employed as exemplified by variouscomputer systems.

The CPU comprises at least one high-speed data processor adequate toexecute program modules for executing user and/or system-generatedrequests. The CPU may be a microprocessor such as the Intel PentiumProcessor and/or the like. The CPU interacts with memory through signalpassing through conductive conduits to execute stored program codeaccording to conventional data processing techniques. Such signalpassing facilitates communication within the DQAS controller and beyondthrough various interfaces.

Interface Adapters

Interface bus(ses) 107 may accept, connect, and/or communicate to anumber of interface adapters, conventionally although not necessarily inthe form of adapter cards, such as but not limited to: input outputinterfaces (I/O) 108, storage interfaces 109, network interfaces 110,and/or the like. Optionally, cryptographic processor interfaces 127similarly may be connected to the interface bus. The interface busprovides for the communications of interface adapters with one anotheras well as with other components of the computer systemization.Interface adapters are adapted for a compatible interface bus. Interfaceadapters conventionally connect to the interface bus via a slotarchitecture. Conventional slot architectures may be employed, such as,but not limited to: Accelerated Graphics Port (AGP), Card Bus,(Extended) Industry Standard Architecture ((E)ISA), Micro ChannelArchitecture (MCA), NuBus, Peripheral Component Interconnect (PCI),Personal Computer Memory Card International Association (PCMCIA), and/orthe like.

Storage interfaces 109 may accept, communicate, and/or connect to anumber of storage devices such as, but not limited to: storage devices114, removable disc devices, and/or the like. Storage interfaces mayemploy connection protocols such as, but not limited to: (Ultra)Advanced Technology Attachment (Packet Interface) ((Ultra) ATA(PI)),(Enhanced) Integrated Drive Electronics ((E)IDE), Institute ofElectrical and Electronics Engineers (IEEE) 1394, fiber channel, SmallComputer Systems Interface (SCSI), Universal Serial Bus (USB), and/orthe like.

Network interfaces 110 may accept, communicate, and/or connect to acommunications network 113. Network interfaces may employ connectionprotocols such as, but not limited to: direct connect, Ethernet (thick,thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring,wireless connection such as EEE 802.11b, and/or the like. Acommunications network may be any one and/or the combination of thefollowing: a direct interconnection; the Internet; a Local Area Network(LAN); Metropolitan Area Network (MAN); an Operating Missions as Nodeson the Internet (OMNI); a secured custom connection; a Wide Area Network(WAN); a wireless network (e.g., employing protocols such as, but notlimited to a Wireless Application Protocol (WAP), I-mode, and/or thelike); and/or the like. A network interface may be regarded as aspecialized form of an input output interface.

Input Output interfaces (I/O) 108 may accept, communicate, and/orconnect to user input devices 111, peripheral devices 112, cryptographicprocessor devices 128, and/or the like. I/O may employ connectionprotocols such as, but not limited to: Apple Desktop Bus (ADB); AppleDesktop Connector (ADC); audio: analog, digital, monaural, RCA, stereo,and/or the like; IEEE 1394; infrared; joystick; keyboard; midi; optical;PC AT; PS/2; parallel; radio; serial; USB; video interface: BNC,composite, digital, RCA, S-Video, VGA, and/or the like; wireless; and/orthe like. A common output device is a video display, which typicallycomprises a CRT or LCD based monitor with an interface (e.g., VGAcircuitry and cable) that accepts signals from a video interface. Thevideo interface composites information generated by a computersystemization and generates video signals based on the compositedinformation. Typically, the video interface provides the compositedvideo information through a video connection interface that accepts avideo display interface (e.g., a VGA connector accepting a VGA displaycable).

User input devices 111 may be card readers, dongles, finger printreaders, gloves, graphics pads, joysticks, keyboards, mouse (mice),trackballs, trackpads, retina readers, and/or the like.

Peripheral devices 112 may be connected and/or communicate with or toI/O and/or with or to other facilities of the like such as networkinterfaces, storage interfaces, and/or the like). Peripheral devices maybe cameras, dongles (for copy protection, ensuring secure transactionsas a digital signature, and/or the like), external processors (for addedfunctionality), goggles, microphones, monitors, network interfaces,printers, scanners, storage devices, visors, and/or the like.

Cryptographic units such as, but not limited to, microcontrollers,processors 126, interfaces 127, and/or devices 128 may be attached,and/or communicate with the DQAS controller. A MC68HC16 microcontroller,commonly manufactured by Motorola Inc., may be used for and/or withincryptographic units. Equivalent microcontrollers and/or processors mayalso be used. The MC68HC16 microcontroller utilizes a 16-bitmultiply-and-accumulate instruction in the 16 MHz configuration andrequires less than one second to perform a 512-bit RSA private keyoperation. Cryptographic units support the authentication ofcommunications from interacting agents, as well as allowing foranonymous transactions. Cryptographic units may also be configured aspart of CPU. Other commercially available specialized cryptographicprocessors include VLSI Technology's 33 MHz 6868 or SemaphoreCommunications' 40 MHz Roadrunner 284.

Memory

A storage device 114 may be any conventional computer system storage.Storage devices may be a fixed hard disk drive, and/or other devices ofthe like. However, it is to be understood that a DQAS controller and/ora computer systemization may employ various forms of memory 129. Forexample, a computer systemization may be configured wherein thefunctionality of on-chip CPU memory (e.g., registers), RAM, ROM, and anyother storage devices are provided by a paper punch tape or paper punchcard mechanism; of course such an embodiment is not preferred and wouldresult in an extremely slow rate of operation. In a typicalconfiguration, memory 129 will include ROM, RAM, and a storage device114. Generally, any mechanization and/or embodiment allowing a processorto affect the storage and/or retrieval of information is regarded asmemory 129. Thus, a computer systemization generally requires and makesuse of memory. However, memory is a fungible technology and resource,thus, any number of memory embodiments may be employed in lieu of or inconcert with one another.

Module Collection

The storage devices 114 may contain a collection of program and/ordatabase modules and/or data such as, but not limited to: an operatingsystem module 115 (operating system); an information server module 116(information server); a user interface module 117 (user interface); aweb browser module 118 (web browser); databases 119; a cryptographicserver module 120 (cryptographic server); Directory Quality AssuranceServer (DQAS) module 125; and/or the like (i.e., collectively a modulecollection). These modules may be stored and accessed from the storagedevices and/or from storage devices accessible through an interface bus.Although non-conventional software modules such as those in the modulecollection, typically and preferably, are stored in a local storagedevice 114, they may also be loaded and/or stored in memory such as:peripheral devices, RAM, remote storage facilities through acommunications network, ROM, various forms of memory, and/or the like.

Operating System

The operating system module 115 is executable program code facilitatingthe operation of a DQAS controller. Typically, the operating systemfacilitates access of I/O, network interfaces, peripheral devices,storage devices, and/or the like. The operating system preferably is aconventional product such as Apple Macintosh OS X Server, AT&T Plan 9,Microsoft Windows NT Server, Unix, and/or the like operating systems.Preferably, the operating system is highly fault tolerant, scalable, andsecure. An operating system may communicate to and/or with other modulesin a module collection, including itself, and/or facilities of the like.Conventionally, the operating system communicates with other programmodules, user interfaces, and/or the like. For example, the operatingsystem may contain, communicate, generate, obtain, and/or provideprogram module, system, user, and/or data communications, requests,and/or responses. The operating system, once executed by the CPU, mayenable the interaction with communications networks, data, I/O,peripheral devices, program modules, memory, user input devices, and/orthe like. Preferably, the operating system provides communicationsprotocols that allow the DQAS controller to communicate with otherentities through a communications network 113. Various communicationprotocols may be used by the DQAS controller as a subcarrier transportmechanism for interacting with the Handle System, such as, but notlimited to: multicast, TCP/IP, UDP, unicast, and/or the like.

Information Server

An information server module 116 is stored program code that is executedby the CPU. The information server may be a conventional Internetinformation server such as, but not limited to, Microsoft's InternetInformation Server and/or the Apache Software Foundation's Apache.Preferably, the information server allows for the execution of programmodules through facilities such as C++, Java, JavaScript, ActiveX,Common Gateway Interface (CGI) scripts, Active Server Page (ASP), and/orthe like. Preferably the information server supports securecommunications protocols such as, but not limited to, File TransferProtocol (FTP); HyperText Transfer Protocol (HTTP); Secure HypertextTransfer Protocol (HTTPS), Secure Socket Layer (SSL), and/or the like.Conventionally, an information server provides results in the form ofweb pages to web browsers, and allows for the manipulated generation ofthe web pages through interaction with other program modules. After aDNS resolution portion of an HTTP request is resolved to a particularinformation server, the information server resolves requests forinformation at specified locations on a DQAS controller based on theremainder of the HTTP request. For example, a request such ashttp://123.124.125.126/myInformation.html might have the IP portion ofthe request “123.124.125.126” resolved by a DNS server to an informationserver at that IP address; that information server might in turn furtherparse the http request for “/myInformation.html” portion of the requestand resolve it to a location in memory containing the information“myInformation.html.” An information server may communicate to and/orwith other modules in a module collection, including itself, and/orfacilities of the like. Most frequently, the information servercommunicates with operating systems, other program modules, userinterfaces, web browsers, and/or the like. An information server maycontain, communicate, generate, obtain, and/or provide program module,system, user, and/or data communications, requests, and/or responses.

User Interface

A user interface module 117 is stored program code that is executed bythe CPU. Preferably, the user interface is a conventional graphic userinterface as provided by, with, and/or atop operating systems and/oroperating environments such as Apple Macintosh OS, e.g., Aqua, MicrosoftWindows (NT), Unix X Windows (KDE, Gnome, and/or the like), and/or thelike. The user interface may allow for the display, execution,interaction, manipulation, and/or operation of program modules and/orsystem facilities through textual and/or graphical facilities. The userinterface provides a facility through which users may affect, interact,and/or operate a computer system. A user interface may communicate toand/or with other modules in a module collection, including itself,and/or facilities of the like. Most frequently, the user interfacecommunicates with operating systems, other program modules, and/or thelike. The user interface may contain, communicate, generate, obtain,and/or provide program module, system, user, and/or data communications,requests, and/or responses.

Web Browser

A web browser module 118 is stored program code that is executed by theCPU. Preferably, the web browser is a conventional hypertext viewingapplication such as Microsoft Internet Explorer or Netscape Navigator(preferably with 128 bit encryption by way of HTTPS, SSL, and/or thelike). Some web browsers allow for the execution of program modulesthrough facilities such as Java, JavaScript, ActiveX, and/or the like.In one embodiment, web browsers are Handle-enabled by way of a browserplug-in software such as the Handle System plug-in available fromwww.cnri.org. In an alternative embodiment Handle support is integratedinto the web browser. Web browsers and like information access tools maybe integrated into PDAs, cellular telephones, and/or other mobiledevices. A web browser may communicate to and/or with other modules in amodule collection, including itself, and/or facilities of the like. Mostfrequently, the web browser communicates with information servers,operating systems, integrated program modules (e.g., plug-ins), and/orthe like; e.g., it may contain, communicate, generate, obtain, and/orprovide program module, system, user, and/or data communications,requests, and/or responses. Of course, in place of a web browser andinformation server, a combined application may be developed to performsimilar functions of both. The combined application would similarlyaffect the obtaining and the provision of information to users, useragents, and/or the like from DQAS enabled nodes. The combinedapplication may be nugatory on systems employing standard web browsers.Such a combined module could be configured to communicate directly withthe DQAS without an intermediary information server to further enhancesecurity.

DQAS Database

A DQAS database module 119 may be embodied in a database that is storedprogram code that is executed by the CPU and its stored data; the storedprogram code portion configuring the CPU to process the stored data.Preferably, the database is a conventional, fault tolerant, relational,scalable, secure database such as Oracle or Sybase. Relational databasesare an extension of a flat file. Relational databases consist of aseries of related tables. The tables are interconnected via a key field.Use of the key field allows the combination of the tables by indexingagainst the key field; i.e., the key fields act as dimensional pivotpoints for combining information from various tables. Relationshipsgenerally identify links maintained between tables by matching primarykeys. Primary keys represent fields that uniquely identify the rows of atable in a relational database. More precisely, they uniquely identifyrows of a table on the “one” side of a one-to-many relationship.

Alternatively, the DQAS database may be implemented using variousstandard data structures, such as an array, hash, (linked) list, struct,and/or the like. Such data structures may be stored in memory and/or in(structured) files. If the DQAS database is implemented as a datastructure, the use of the DQAS database may be integrated into anothermodule such as the DQAS module. Databases may be consolidated and/ordistributed in countless variations through standard data processingtechniques. Portions of databases, e.g., tables, may be exported and/orimported and thus decentralized and/or integrated. In one non-limitingexample embodiment, the database module 119 includes tables such as butnot limited to a UNI (e.g., Handle, DOI and/or other UNIs) table 119 a,URL table 119 b, metadata table 119 c, multiple resolution table 119 d,a policy table 119 e, and/or the like. All the tables may be related by(enhanced) DOI key field entries as they are unique. In an alternativeembodiment, these tables have been decentralized into their owndatabases and their respective database controllers (i.e., individualdatabase controllers for each of the above tables). Of course, employingstandard data processing techniques, one may further distribute thedatabases over several computer systemizations and/or storage devices.Similarly, configurations of the decentralized database controllers maybe varied by consolidating and/or distributing the various databasemodules 119 a-e. The DQAS may be configured to keep track of userrequests and various transactions tracking via database controllers.

A DQAS database may communicate to and/or with other modules in a modulecollection, including itself, and/or facilities of the like. Mostfrequently, the DQAS database communicates with a DQAS module, otherprogram modules, and/or the like. The database may contain, retain, andprovide information regarding other nodes and data.

Cryptographic Server

A cryptographic server module 120 is stored program code that isexecuted by the CPU 103, cryptographic processor 126, cryptographicprocessor interface 127, cryptographic processor device 128, and/or thelike. Preferably, cryptographic processor interfaces will allow forexpedition of encryption and/or decryption requests by the cryptographicmodule; however, the cryptographic module, alternatively, may run on aconventional CPU. Preferably, the cryptographic module allows for theencryption and/or decryption of provided data. Preferably, thecryptographic module allows for both symmetric and asymmetric (e.g.,Pretty Good Protection (PGP)) encryption and/or decryption. Preferably,the cryptographic module allows conventional cryptographic techniquessuch as, but not limited to: digital certificates (e.g., X.509authentication framework), digital signatures, dual signatures,enveloping, password access protection, public key management, and/orthe like. Preferably, the cryptographic module will facilitate numerous(encryption and/or decryption) security protocols such as, but notlimited to: checksum, Data Encryption Standard (DES), Elliptical CurveEncryption (ECC), International Data Encryption Algorithm (IDEA),Message Digest 5 (MD5, which is a one way hash function), passwords, RC5(Rivest Cipher), Rijndael, RSA (which is an Internet encryption andauthentication system that uses an algorithm developed in 1977 by RonRivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA),Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS),and/or the like. The cryptographic module facilitates the process of“security authorization” whereby access to a resource is inhibited by asecurity protocol wherein the cryptographic module effects authorizedaccess to the secured resource. A cryptographic module may communicateto and/or with other modules in a module collection, including itself,and/or facilities of the like. Preferably, the cryptographic modulesupports encryption schemes allowing for the secure transmission ofinformation across a communications network to enable a DQAS module toengage in secure transactions if so desired by users. The cryptographicmodule facilitates the secure accessing of resources on DQAS andfacilitates the access of secured resources on remote systems; i.e., itmay act as a client and/or server of secured resources. Most frequently,the cryptographic module communicates with information servers,operating systems, other program modules, and/or the like. Thecryptographic module may contain, communicate, generate, obtain, and/orprovide program module, system, user, and/or data communications,requests, and/or responses.

Information Access Multiple Resolution Server (IAMRS)

An IAMRS module 125 is stored program code that is executed by the CPU.Generally, the DQAS affects accessing, obtaining and the provision ofinformation, and/or the like between nodes on a communications network.The IAMRS has the ability to resolve UNIs to multiple instantiations.Generally, the IAMRS acts as a lookup facility to create, maintain, andupdate associations between a given piece of information, its DOI, andits current locations. The IAMRS coordinates with the DQAS database toidentify nodes that may be useful for improving data transfer forrequested information, for resolving to various formats of therequesting information, providing an enhanced mechanism to createqueries regarding the information, and/or the like. An IAMRS enablingaccess of information between nodes may be developed by employingstandard development tools such as, but not limited to: C++, shellscripts, Java, Javascript, SQL commands, web application serverextensions, Apache modules, Perl scripts, binary executables, and/orother mapping tools, and/or the like. In one non-limiting exampleembodiment, the IAMRS server employs a cryptographic server to encryptand decrypt communications. The IAMRS may service requests, updateassociation information for UNIs, and much more. A DQAS module maycommunicate to and/or with other modules in a module collection,including itself, and/or facilities of the like. Most frequently, theIAMRS module communicates with a DQAS database, operating systems, otherprogram modules, and/or the like. The IAMRS may contain, communicate,generate, obtain, and/or provide program module, system, user, and/ordata communications, requests, and/or responses.

Directory Quality Assurance Server (DQAS)

A DQAS module 135 is stored program code that is executed by the CPU.Generally, the DQAS tests, validates, and/or verifies UNIs so that usersmay access, obtain and provide information, between nodes on acommunications network, and/or the like. The DQAS maintains theintegrity between a UNI and its associated information by testing thatthe appropriate data is available at locations associated with the UNI.In one non-limiting example embodiment, the DQAS may be integrated intoa UNI registration system (e.g., an Information Access RegistrationServer Controller (IARS)), which has the ability to register resourcenames (e.g., Handles) thereby effecting an association between theresource name and a piece of information and/or the information'slocation. Registration of a resource name may be associated withmultiple instantiations. Generally, the IARS acts as a facility tocreate, maintain, register, and update associations between a givenpiece of information, its DOI, and its current locations. The DQAS mayadd the ability to validate UNIs to an IARS. Alternatively, the DQAS mayoperate in a stand alone mode separate from the IARS. In eitherembodiment, the DQAS may be used to generate tags, which are embeddedinto information represented by the DOI so that the information may bevalidated. The DQAS coordinates with the DQAS database to identify nodesthat may be useful for validating UNI and associated informationintegrity, improving data transfer for requested information, resolvingto various formats of the requesting information, providing an enhancedmechanism to create queries regarding the information, and/or the like.A DQAS enabling access of information between nodes maybe be developedby employing standard development tools such as, but not limited to:C++, shell scripts, Java, Javascript, SQL commands, web applicationserver extensions, Apache modules, Perl scripts, binary executables,and/or other mapping tools, and/or the like. In one non-limiting exampleembodiment, the DQAS server employs a cryptographic server to encryptand decrypt communications. The DQAS may service requests, redirectrequests, update association information for UNIs, and much more. A DQASmodule may communicate to and/or with other modules in a modulecollection, including itself, and/or facilities of the like. Mostfrequently, the DQAS module communicates with a DQAS database, an IAMRSmodule, and IARS module, operating systems, other program modules,and/or the like. The DQAS may contain, communicate, generate, obtain,and/or provide program module, system, user, and/or data communications,requests, and/or responses.

Distributed DOAS

The functionality of any of the DQAS node controller components may becombined, consolidated, and/or distributed in any number of ways tofacilitate development and/or deployment. Similarly, the modulecollection may be combined in any number of ways to facilitatedeployment and/or development. To accomplish this, one must simplyintegrate the components into a common code base or in a facility thatcan dynamically load the components on demand in an integrated fashion.

The module collection may be consolidated and/or distributed incountless variations through standard data processing and/or developmenttechniques. Multiple instances of any one of the program modules in theprogram module collection may be instantiated on a single node, and/oracross numerous nodes to improve performance through load balancing dataprocessing techniques. Furthermore, single instances may also bedistributed across multiple controllers and/or storage devices; e.g.,databases.

All program module instances and controllers working in concert may doso through standard data processing communication techniques.

The preferred DQAS controller configuration will depend on the contextof system deployment. Factors such as, but not limited to, the capacityand/or location of the underlying hardware resources may affectdeployment requirements and configuration. Regardless of if theconfiguration results in more consolidated and/or integrated programmodules, results in a more distributed series of program modules, and/orresults in some combination between a consolidated and/or distributedconfiguration, communication of data may be communicated, obtained,and/or provided. Instances of modules (from the module collection)consolidated into a common code base from the program module collectionmay communicate, obtain, and/or provide data. This may be accomplishedthrough standard data processing techniques such as, but not limited to:data referencing (e.g., pointers), internal messaging, object instancevariable communication, shared memory space, variable passing, and/orthe like (intra-application communication).

If module collection components are discrete, separate, and/or externalto one another, then communicating, obtaining, and/or providing datawith and/or to other module components may be accomplished throughstandard data processing techniques such as, but not limited to:Application Program Interfaces (API) information passage; (distributed)Component Object Model ((D)COM), (Distributed) Object Linking AndEmbedding ((D)OLE), and/or the like), Common Object Request BrokerArchitecture (CORBA), process pipes, shared files, and/or the like(inter-application communication). Messages sent between discrete modulecomponents for inter-application communication or within memory spacesof a singular module for intra-application communication may befacilitated through the creation and parsing of a grammar. A grammar maybe developed by using standard development tools such as lex, yacc,and/or the like, which allow for grammar generation and parsingfunctionality, which in turn may form the basis of communicationmessages within and between modules. Again, the preferable embodimentwill depend upon the context of system deployment.

Finally, it is to be understood that the logical and/or topologicalstructure of any combination of the module collection and/or the presentinvention as described in the figures and throughout are not limited toa fixed execution order and/or arrangement, but rather, any disclosedorder is exemplary and all functional equivalents, regardless of order,are contemplated by the disclosure. Furthermore, it is to be understoodthat such structures are not limited to serial execution, but rather,any number of threads, processes, services, servers, and/or the likethat may execute asynchronously, simultaneously, synchronously, and/orthe like are contemplated by the disclosure.

IP Addressing

Users access communications networks through addresses. Addressesrepresent locations. Users traverse locations in a communicationsnetwork hoping to find information. A common communications addressingscheme employs the IP address. The IP address may be likened to the realworld by analogy to a street address. The IP address itself is asequence of numbers, e.g., 209.54.94.99, and commonly has an associatedname, e.g., www.contentdirections.com. A distributed database registrymaintains the associated pairs of names and IP addresses and serves toresolve associated names into corresponding IP addresses. This allowspeople to remember and use names, e.g., www.report.com, instead of beingforced to memorize and use a series of numbers, e.g., 209.54.94.99.These distributed databases assisting in the name resolution of IPaddresses are commonly referred to as Domain Name Servers (DNS).

It is common for IP addresses to be embodied as Universal ResourceLocators (URLs) that append even more navigation information into anaddress. Users may employ software to access information stored at URLsthrough the use of HTTP. An example is when a user specifies“http://www.report.com/reports/1999/IncomeStatement.html” in a webbrowser. Typically this further navigation information, i.e.,“/reports/1999/IncomeStatement.html,” provides a specific storagelocation within a computer server. This further navigation location maybe likened to a real world address more specific than a street addressthat includes information such as a company name, department, and roomnumber. This further navigation location is typically not Handled orresolved by DNSs, but instead by an information server at the resolvedIP address. For example, an information server at the resolved addressof 123.123.123.123 for www.report.com would interpret and returninformation at a local location of “/reports/1999/IncomeStatement.html”within the server. An Information Server is a means for facilitatingcommunications between a communication network and the computer serverat a particular IP address. Commercial examples of an Information Serverinclude Apache. An Information Server may be likened to a maildepartment for a business that further routes correspondence toappropriate locations within the business.

FIGS. 2 and 3 illustrate that IP addressing mechanisms do not maintainan association with information as it moves across a communicationsnetworks. Web page links generally employ HTTP, which in turn relies onIP addressing. Thus, URL links simply point to a location on acommunication network and are not necessarily associated with anyspecific information. For example, a URL link referencing www.news.comwill have different information associated between the URL and theinformation made available at the www.news.com location as informationat the location is updated daily. In many instances, locationsthemselves may disappear as companies move information, move theiroperations, go out of business, etc.

For example, a report entitled “Company Sales for 1999” 222l existing ata location www.report.com/1999/Report.html 208 may be moved towww.reportarchives.com/1999/Old-report.html 310, e.g., because theinformation was sold from one entity to another, archived, or for manyother reasons. The report at www.report.com/1999/Report.html 208 mayhave had 5 million web pages and URL links referencing the location 244,and when users attempt to access the information they may well receive a“404 File not found” error 309 because that location no longer existsand/or no longer contains the desired information. The error resultsbecause the DNSs were designed to always resolve users' requests to alocation and because DNSs are not designed to maintain an associationbetween URLs and a specific instantiation of information.

FIG. 2 depicts a web page 201, a user entered address 202, a document203, and a memory device 204 all employing URLs and consequently IPaddressing in an attempt to reference a piece of information (the report“Company Sales for 1999”) 222. Then in FIG. 2, the information 222 ismoved from its original location 208 (for example atwww.report.com/1999/Report.html) to a new location 310 of FIG. 2 (forexample www.report.com/1999/Archives.html). In FIG. 3, this results inbreaking 301-304 all the URLs 244 referencing the location and producesthe dreaded “404 file not found” error 309 for all users and URLs makingreference to the location (www.report.com/1999/Report.html) 208.

Handle System

Once a piece of information has been assigned a DOI and has been madeavailable, the DOI system needs to be able to resolve what the user ofthe DOI wants to access. The technology that is used to manage theresolution of DOIs is better known as the “Handle System,” and will bedescribed in more detail below. THE DOI HANDBOOK provides a generaloverview of basic DOIs. In a nutshell, the Handle System includes anopen set of protocols, a namespace, and an implementation of theprotocols. The protocols enable a distributed computer system to storeHandles (such as DOIs) of digital content and resolve those Handles intothe information necessary to locate and access the content, to locateand access information related to the content, or to locate and access(i.e., provide an interface to) services associated with the content.This associated information can be changed as needed to reflect thecurrent state of the identified content without changing the DOI, thusallowing the name of the item to persist over changes of location andother state information. Combined with a centrally administered DOIregistration agency, the Handle System provides a general-purpose,distributed global naming service for the reliable management ofinformation and services on networks over long periods of time. It isimportant to note that throughout the present disclosure that “source,”“content” and/or “information” made accessible through the DOI systemmay comprise any identifiable content, source, information, services,transactions, and work of authorship, including articles, books,intangible objects, music albums, people, tangible physical objects,and/or the like further including selected discrete portions and/orcombinations thereof. The accessible information may be a URL to anapplication that initiates a service, a transaction, provides aselection mechanism, and/or the like. In one non-limiting example, theDOI may even be associated with information identifying a human beingsuch as a social security number, telephone number, and/or the like. Inanother non-limiting example, the DOI may be associated with softwaremodules, programming “objects,” or any other network-based resource.Furthermore, a DOI can be used to represent most anything including theonline representation of physical products (e.g., items currentlyidentified by UPC or bar codes). In such an example, DOIs could resolveto the manufacturer's catalog page describing or offering the product,or even, in a multipleresolution scenario, offer all services related tothe object such as where to go to get the item repaired; where to findreplacement parts; what the new or replacement product is; what kinds ofpricing or leasing options are available, etc. Other example embodimentsimplementing DOIs include: representing different modules of softwarethat may operate in distributed fashion across a communications network;telephone numbers for Voice-over-IP technology; gene sequences; medicalrecords and/or other permanent records (DOIs will be especially usefulwith permanent records protected via encryption and/or other method thatmight invoke a certificate or decryption key); and/or the like. Anotherexample embodiment for a DOI is to represent the permanent location of atemporary and/or dynamic value such as, but not limited to a currentstock quote; current bid and offer prices (for stocks and/or any otherkind of auction and/or exchange); a company's current annual report(versus different DOIs for different prior year annual reports); and/orthe like.

Users may access information through Digital Object Identifiers (DOIs).DOIs are associated with (i.e., are names for) information itself. DOIsare instances of “Handles” and operate within the framework of the“Handle system.” A DOI allows for access to persistently associatedinformation. The DOI is a string of characters followed by a separatorfurther followed by a string of characters, e.g., 10.1065/abc123def. Itshould be noted and re-emphasized that although the present disclosuremay make mention of specific sub-types of UNIs such as “URNs,” “DOIs”and “Handles,” the present disclosure applies equally well to the moregeneric types of UNIs, and as such, the present disclosure should beregarded as applying to UNIs in general where any UNI sub-type ismentioned, unless stated otherwise. Furthermore, although the HandleSystem, DOIs, and their supporting technologies and conventions, whichare in use today, are a contemplated forum for the present invention, itshould be noted that it is contemplated that the present invention maybe applied to other forums based upon current and yet to be conceivedconventions and systems.

DOIs

Users employing DOIs to access information know they will resolve andaccess only associated information. In contrast to URLs that referencelocations, DOIs are names for information, which can be used to look upthat information's location and other attributes, as well as relatedservices. It is envisioned that information may be any information aswell as any computer-readable files, including e-books, music files,video files, electronic journals, software, smaller portions and/orcombinations of any of the aforementioned content as well. It should benoted that since the electronic content will be made available over acommunications network, hereinafter this application refers to suchavailable information as being published on a communications network.

A DOI is a permanent and persistent identifier given to a piece ofinformation made available on a communications network and registered inan electronic form, so that even if the location (i.e., URL), format,ownership, etc. of the content or associated data changes, users will beable to access the associated data. DOIs, or Handles, may be distributedto users in lieu of a URL. A user may, access information associatedwith a particular DOI by selecting or entering the DOI in aHandle-enabled web browser much like a URL hyperlink. Many types ofbrowsers may be enabled by way of browser plug-in software such as theHandle System plug-in available from www.cnri.org. Such an attempt toaccess DOI associated information triggers an automated process to lookup a resource's current location. The current location of the resourceis associated with the resource's DOI in a centrally managed directorymade available by the Handle System, which in turn directs the user(i.e., the user's web browser) to the resource's current location. Thisdirection is often accomplished by returning a current URL associatedwith the selected DOI and corresponding information.

FIG. 4 illustrates the access of information through DOIs in contrast toFIGS. 2 and 3 above. Initially, the information (report of “CompanySales for 1999) 222 is given a DOI through a registration process.Instead of employing URLs, users reference 444 the information using theDOI through web pages 401, typed entry in a web browser 402, documents403, devices 404, barcodes 406, and/or the like. When users engage theDOI links 444, they are resolved in a centralized DOI directory 411 andthe requesting users are given a URL link 244 to the information's 222initial location (www.report.com/1999/Report.html) 208. Upon theinformation being moved 434 from its initial location(www.report.com/1999/Report.html) 208 to a new location(www.report.com/1999/Archives.html) 310, the publisher of theinformation 410 would inform the DOI centralized directory 445 of thenew location for the information by sending an updated URL 245referencing the new location. Thereafter, if users 401-404 attempt toaccess the information through the DOI links 444, the DOI directory willproperly provide the new location 310 by way of the updated URL 245.

As noted above, DOIs may not only be used to identify information, butalso smaller portions thereof. For example, according to the DOI system,it is possible for a book to have one DOI, while each of its chapterswould have other unique DOIs to identify them; furthermore, each figurein the book may have yet other unique DOIs to identify them. In otherwords, according to the DOI system, it is possible to identifyinformation with variable granularity as desired by the contentpublishers. Furthermore, it is envisioned that just as Universal ProductCodes (commonly expressed as ‘bar-codes’ on consumer products) allow,for example, a supermarket's cash registers, inventory computers,financial systems, and distributors to automate the supply chain in thephysical world, the present disclosure provides a mechanism foremploying DOIs to empower all kinds of agents in the world of electronicpublishing to automate the sale of digital content (and the licensing ofrights to that content) across the Internet in an efficient manner,since each piece of saleable content would have associated with it aglobally unique DOI, which could be used as a product identificationcode in transactions between agents.

Handle Structure

The Handle System employs a pre-determined set of policies for efficientand user-friendly utilization thereof, some of which of which are listedbelow. The use of the Handle System for DOI resolution should ideally befree to users, with the costs of operation of the system possibly borneby the publishers. All DOIs are to be registered with a global DOIregistry. Registrants are responsible for the maintenance of state dataand metadata relating to DOIs that they have registered. The syntax ofthe DOI follows a standardized syntax. In use, the DOI will be an opaquestring (dumb number). DOI registration agencies will manage theassignment of DOIs, their registration and the declaration of themetadata associated with them.

FIGS. 5 and 6 provide a schematic view of a Handle 600. A Handle 600 hastwo components, the prefix 501 and the suffix 602. The prefix 501 andthe suffix 502 are separated by a forward slash 507. The Handle 500 mayincorporate any printable characters from almost every major languagewritten or used today. There is no specified limitation on the length ofeither the prefix 501 or the suffix 502. As a result, it is envisionedthat there are an almost infinite number of Handles available. It isimportant to ensure that the combination of the prefix 501 and thesuffix 502 is unique for supporting the integrity of the Handle System.Thus, the DOI registration agency will award a unique prefix 501 to apublisher. In one embodiment; the registration agency may put theresponsibility on these publishers for ensuring that the suffix 502assigned is unique as well. This may be achieved with a registrationtool running on the user's client computer system. In anotherembodiment, the registration agency will ensure that the suffix 502 isunique by applying various suffix generation algorithms as discussedthroughout this disclosure. The Registration Agency and the HandleSystem administrators will both verify uniqueness of any new Handlebefore depositing it in the Handle System. The Registration Agencydeposits DOI records with the Handle System. The Handle System in turnservices DOI resolution requests through a DOI directory.

The prefix 501 itself has two components separated by a prefix separator506, which is a period. The first part of the Handle prefix is theHandle type 504. The second part of the Handle prefix is the Handlecreator 505. The Handle type 504 identifies what type of Handle systemis being used. When the Handle type 504 starts with a “10” the Handle isdistinguished as being a DOI as opposed to any other implementation typeof the Handle System. The next element of the prefix, separated by aperiod, is the Handle creator 505, which is a number (or string ofcharacters) that is assigned to an organization that wishes to registerDOIs. Together, these two elements 504 and 505 form the unique publisherprefix portion of the DOI. There is no limitation placed on the numberof Handle (or specifically DOI) prefixes that any organization maychoose to apply for. As a result, a publishing company, for example,might have a single DOI prefix 501, or might have a different one foreach of its journals, or one for each of its imprints. While generally aprefix 501 may be a simple numeric string, the scope of the HandleSystem is not limited thereby. Thus, a prefix 501 may also utilizealphabetical characters or any other characters.

The suffix 502 is a unique string of alphanumeric characters, which, inconjunction with a particular prefix 501, uniquely identifies a piece ofinformation. It should be appreciated that the combination of the prefix501 for a publisher and the unique suffix 502 provided by the publisheravoids the need for the centralized allocation of DOI numbers. Thesuffix 502 may be any alphanumeric string that the publisher chooses, solong as it is unique among all suffixes registered in conjunction withthe publisher's prefix.

FIG. 6 provides a view of another embodiment of the DOI 600, in which atextbook's ISBN number serves as the suffix 602. Consequently, where itis convenient, the publisher of the underlying content may choose toselect as the suffix 602 any other identification code accorded to theoriginal piece of content.

Enhanced DOI

FIG. 5 further illustrates an enhanced DOI 510 grammar. One non-limitingexample embodiment of an enhancement to the DOI grammar is embodied asan enhanced prefix 511. However, it is fully contemplated that analternative and/or complimentary enhanced suffix (not illustrated) maybe similarly appended to the DOI 500. The enhanced prefix 511 iscomprised of an enhancement grammar target 517 and enhancement separator514, which is an “@” symbol, but it is understood any other charactermay be designated as the enhancement separator. The enhancement grammartarget 517 may itself be any string of characters other than theenhancement separator 514. The enhancement grammar target 517 may beemployed for the purpose of having the DOI 500 resolve to multipleversions of a specified information as will be described in greaterdetail throughout this disclosure. In a further enhanced embodiment, theenhancement grammar target 517 may itself be further comprised of anenhancement grammar verb 512 and enhancement grammar target object 513separated by an enhancement target separator 516, e.g., a period. Ofcourse the enhancement target separator 516 may be designated as anycharacter(s). In one example embodiment, the enhancement grammar verb512 acts as a modifier to select amongst a plurality of multipleresolution targets for a DOI, and the enhancement grammar target object513 is a value passed to the target object and/or a Handle systemresolution server for further action.

Handle System Metadata

A DOI 500 is merely an identification number that does not necessarilyconvey any information about its associated information. As a result, itis desirable to supplement the DOI with additional information regardingthe addressed information to enable users to perform efficient anduser-friendly searches for retrieving the desired content over acommunications network. To allow easy identification of information, thepresent invention provides for the use of metadata, which is descriptivedata about the identified information. While metadata may be any datastructure that is associated with a DOI, according to one embodiment,the metadata will be comprised of a few basic fields that can accuratelyand succinctly identify the published information. According to thisembodiment, the metadata will comprise an identifier associated with theentity from a legacy identifier scheme such as the InternationalStandard Book Number (ISBN) for a book, title of the published content,type of content being published (such as book, music, video, etc.),whether the content is original or a derivation, a primary author of thecontent, the role of the primary author in creating the content, thename of the publisher, and/or the like. As different types of contentmay require different metadata for describing it, one aspect of the DOIsystem envisions the use of different metadata for different types ofcontent.

According to one example embodiment, metadata will be made available toany user of the DOI system to enable them to find the basic descriptionof the entity that any particular DOI identifies. This basic descriptionwill allow the user to understand some basic things about the entitythat published the content or the content itself.

As a result, to find out what information the DOI identifies, it isdesirable to resolve it, and then review associated metadata because theDOI links the metadata with the content it identifies and with othermetadata about the same or related content. In one embodiment, themetadata allows for the recognition of the information identified by theDOI 500 as well as its unambiguous specification. The metadata will alsoallow for the interaction between the information and other contents inthe network (and with metadata about those entities).

DOI Information Access

FIGS. 7 and 8 provide an overview of the resolution mechanism forallowing users to access the desired information by merely providing theDOI to the DOI Handle system. Resolution in the present context includesthe submitting of an identifier to a network service and receiving inreturn one or more pieces of current information related to theidentifier. According to one embodiment of the DOI system, shown in FIG.7, the user uses her web browser 700 client to point to contentidentified by a particular DOI 710. This DOI 710 has only one URLassociated with it, and must, resolve to that URL. As a result, when theuser makes a request for underlying content identified by a particularDOI 710, the user is directed to URL 720, where the desired contentlies.

As such, this mechanism allows the location of the information to bechanged while maintaining the name of the entity as an actionableidentifier. If the publisher changes the location of the content, thepublisher must merely update the DOI's entry in the Handle Systemdatabase to ensure that the existing DOI 710 points to the new locationof the content. As a result, while the location of the content haschanged, the DOI remains the same and users are able to access thecontent from its new location by using the existing DOI.

FIG. 8 provides an overview of a DOI system where users may use a DOIfor resolving a request for one piece of content, out of a plurality ofavailable identical copies of the same piece of content that areidentified by the same DOI, as well as the location of data about thepiece of content, and services associated with the content (such aspurchasing the content). Thus, the user uses the web browser 800 andprovides the necessary DOI 830. The DOI 830 may be structured todescribe the type of service desired 835. As a result, the DOI system isable to resolve the particular piece of content 840 that the userdesires to access.

FIG. 9 provides an overview of the sequence of actions that a userperforms to access information, in accordance with the presentinvention. Initially, the user launches the browser client 900 on acomputing device 905, such as personal computer, personal digitalassistant (PDA), and/or the like. The user engages the browser 900 tomake a DOI query. The DOI query is forwarded to the DOI Directory Server910 over a communications network. The system of the DOI DirectoryServer 910 examines the DOI against the entries stored therein andforwards the appropriate URL to the browser 900 on the user's computer900, in a manner that is invisible to the user. As a result, the browseris pointed to the desired content on a server with the appropriatepublisher information 920. Finally, upon receipt of the request from theuser's browser, the publisher 920 forwards the desired information tothe user, which may be accessed in the browser client 900.

FIG. 10 provides a more complete view of the sequence of actions that auser performs to access content information, as shown in FIG. 9. Asnoted above, the user launches the browser client 1000 on a computingdevice 1005. The user engages the browser 1000 to make a DOI query. TheDOI query is forwarded to the DOI Directory Server 1010 over thecommunications network. The system of the DOI Directory Server 1010examines the DOI against the entries stored therein. As a result of thechecking of the DOI against the entries stored in the DOI DirectoryServer 1010, the DOI Directory Server 1010 determines where the DOI mustlead the user 1025. The appropriate URL for the content is automaticallyforwarded to the user's browser 1000, without any intermediateintervention or action by the user. As a result, the browser 1000 ispointed to the appropriate publisher 1020 whose server is addressed bythe underlying URL. The URL is used by the publisher's server 1020 todetermine the exact location for content desired by the user, and thepublisher's server 1020 forwards the appropriate content 1030 to theuser.

FIG. 11 provides an overview of some of the exemplary mechanisms foraccessing information over a communications network by resolving a DOIto obtain the URL where the desired content is located, in accordancewith the present invention. According to one embodiment, the user maydirectly provide the DOI and the DOI system retrieves and forwards theappropriate content to the user by simply linking to the appropriateURL. According to another embodiment, the user may provide informationrelated to some of the fields included in the metadata, whereupon a DOIlookup service identifies the appropriate DOI, which in turn may beresolved to the desired content's location. As shown in FIG. 11,according to one embodiment, a search engine 11010 may be provided to auser. In one embodiment, the search engine is offered and disposed incommunication with the registration agency's DOI and metadata database.In an alternative embodiment, a search engine such as www.google.com maybe adapted to submit queries to the registration agency's databases. Theuser searches for the appropriate DOI by providing some identifyinginformation to the search engine 11010. The search engine 11010 uses theidentifying information provided and searches a database of metadata toretrieve the DOI associated with the provided metadata information. Thusthe user conducting the search may be presented with returned DOIs fromthe metadata database and/or URLs resolved from said returned DOIs. Theretrieved DOI is sent to the DOI directory 11011, which resolves the URLwherein the desired content is located by a publisher 11040. Finally,the user's browser is pointed to the appropriate content 11060.

According to another embodiment, the user may provide the DOI 11015 inthe address window 11020 of a browser 11025. If the user's web browseris not capable of natively processing DOIs, then the DOI 11015 maycontain the address of a proxy server for the DOI directory 11011, whichin FIG. 11 is “dx.doi.org.” As a result, the browser is pointed to theDOI directory 11011 located at dx.doi.org, which resolves the URL atwhich the desired content is located by a publisher 11040 and points theuser's browser thereto.

According to another embodiment, the DOI may be embedded in a documentor some form of information 11030, whereupon clicking the DOI directsthe user to the appropriate DOI directory 11011, which determines theURL at which the desired content is located and points the user'sbrowser thereto.

According to another embodiment, the DOI may be provided on a memory11040, such as a CD-ROM or a floppy disk, whereupon the memory mayautomatically, or upon being activated, direct the user to theappropriate DOI directory 11011, which resolves the URL at which thedesired content is located and points the user's browser thereto.

According to yet another embodiment, the DOI may be provided in printedform to a user, who enters the DOI manually as above or by way ofoptical and/or mechanical peripheral input device.

FIG. 12 provides an overview of another embodiment of the exemplarymechanisms for retrieving information over a communications network,whereupon the DOI system resolves a DOI to obtain the URL where thedesired information is located. According to this embodiment, aplurality of DOI directories 1210 exist as a distributed DOI directoryand form a Handle System 1200. In one embodiment, the distributed DOIdirectory acts and responds to requests as if it were a singulardirectory 11011. Otherwise resolutions take place similarly as in FIG.11.

FIG. 13 provides an overview of an exemplary DOI system, in accordancewith the present invention, wherein the publishers, the DOI registrationservice and the Handle System collaborate together to create anefficient DOI system. The prefix holder 1355 may submit information to aDOI registration service 1300 comprising a DOI 1342 and associatedmetadata 1366. The prefix holder who has already been assigned a uniqueprefix 501, requests that a suffix 502 be assigned to a piece of content1366. The registration service 1300 is responsible for parsing and/orreformatting the user's streams of submitted information 1342, 1366 forsubsequent deposit in a Handle system 1350 and/or metadata database1310. As noted above, the scope of the content that can be addressedusing a DOI is unlimited. As a result, the content 1366 may comprise anyinformation and work of authorship, including articles, books, musicalbums, or selected discrete portions thereof. In addition to providinga DOI 500, the publisher 1342 collects metadata for the content 1366.The metadata may comprise the content's DOI 500, a DOI genre, anidentifier, title, type, origination, primary agent, agent's role,and/or the like. It may also comprise listings of associated serviceshaving to do with the identified piece of content offered by variousparties, such as the locations of web pages where a piece of content maybe purchased online.

Once the publisher 1342 has assigned the suffix 502 to the content 1366and collected the necessary metadata, the DOI 500 and the metadata aretransmitted to the DOI registration service 1300. The DOI registrationservice 1300 maintains a database of DOIs 500, metadata of all theregistered content 1366, as well as the URL at which the content 1366 islocated. According to the present invention, the DOI registrationservice 1300 forwards the metadata to a metadata database 1310, 119 c ofFIG. 1, which may or may not be integrally maintained by the DOIregistration service 1300.

The DOI registration service 1300 may use the collected metadata forproviding it to other data services 1320 or for providing value addedresources 1330 to the users. In addition, the DOI registration service1300 sends the appropriate DOI Handle data to the Handle System 1350,which may comprise a plurality of DOI Directory Servers 1341.

Handle System Multiple Resolution Model

FIG. 14 illustrates one non-limiting example of the IAMRS 14006interacting with various entities. Publishers 14012 may wish to maketheir information available through different locations, in differentformats, in different contexts, for different purposes and uses. In sodoing, publishers may register a single DOI 14001 in an enhanced Handlesystem 14008 with multiple resolutions 14005, 14021-14023. In part, theenhanced system is a multiple resolution system. Publishers may wish toprovide multiple resolutions for a DOI to enhance the use and access oftheir information to customers 14001 such as individuals, libraries,corporations, universities, and/or the like, and information resellers(infomediaries) 14002 such as retailers/distributors, aggregators,syndicators, search services, Abstracting & Indexing services,subscription agents, vertical portals, and/or the like. For example,retailers/distributors 14002 may require a publisher's information to belocated on its servers so as to properly account and charge for accessto the information; in such a case an enhanced DOI service request 14010by customers 14001 through a communication network 14004 to an enhancedHandle system 14008 would select 14030 a PURCHASE record associated withURLI 14005. URLI would then be redirected back to the customer 14007through the communications network 14004. Publishers may also providevarious locations for rights clearance 14021, price quotes 14022, andaccessing metadata 14009, 14023.

Handle System Registration Model

FIGS. 15 and 16 illustrate non-limiting examples of the DQAS 15001interacting with various entities. FIGS. 15 and 16 overview theenvironment depicted in FIG. 14 highlighting the registration facilities15002 of the DQAS 15001. Publishers 14012 may wish to make theirinformation available through different locations, in different formats,in different contexts, for different purposes and uses. In so doing,publishers may register a DOI 15020 and associated metadata 15010 in anenhanced Handle system 14008 and metadata database 14009 with aregistration facility 15002. In one embodiment, the metadata isseparated from the DOI 15020 at the registration facility 15002 and themetadata 15011 is sent to the metadata database 14009 in a first phaseof a two phase commit procedure. In the second phase, the DOIs, URLs andany other associated pointers 15012 are separated from the metadata15010 and sent with any security authorization information (e.g., apassword) to the Handle system 14008 across a communications network14004. In an alternative embodiment, a user may request to register aDOI without metadata so that it is not made public and/or not madeavailable for searching; in one embodiment, a registration agency maycharge the user for such an “unpublished DOI.” Upon successfulregistration of both the associated metadata 15011 in the metadatadatabase 14009 and the DOIs 15012 in the Handle system 14008,registration will be deemed successful. If either registration stepfails, the associated data in the other step or steps will be removedfrom the database. The registration facility will provide XML ortag-based reporting and error handling with regard to this two-phasecommit procedure, which will allow registrants to automate the handlingof error conditions. Furthermore, publishers may wish to ensure thattheir information remains available and accessible through the HandleSystem and request that the registration facility 15002 perform variousquality assurance tests to validate that DOIs in the Handle System 14008properly resolves to associated information.

In one embodiment, as part of the registration process, the registrationfacility provides publishers with a tag to be embedded into theinformation being registered so that it may be later verified. This tagmay be a checksum, digital certificate, digital signature, DOI,encryption key, password, almost any form of security authorization,and/or the like. Any code may be embedded as a tag as long as the code,once recognized, can be used to establish the validity of theinformation. In one embodiment, the tag needn't be guaranteed to beunique; e.g., the tag could merely be a tag that says “<SOURCE TAGVALIDATOR>Valid Information</SOURCE TAG VALIDATOR>”. Of course, usingtags that are more unique reduces the likelihood that tag information isincorrectly validated. The tag itself may be of any format as specifiedby an information owner. Response parsers may be programmed by policiesto look for custom tags. In one embodiment, XML codes are appended toinformation for source tag validation. Furthermore, a three phaseautomatic hosting and registration process (i.e., a two phase commitwith the additional phase of automatically taking content from a user,hosting it, and making it available for resolution with a registered DOIand/or any associated metadata) may employ such ping validation. In suchan embodiment, upon transferring content from the client to a suitablestorage facility, the DQAS may validate the source and/or locationaddress of the source by ping testing the location addresses and/orsource, and/or employing various other validation techniques asdescribed throughout the present disclosure. In such an embodiment, theDQAS would be integrated into a registration agency capable ofthree-phase automatic hosting and registration such as an InformationAccess Registration Server (IARS) Controller, and/or the like. By addingvalidation to the three-phase automatic hosting and registrationfacility, a three-phase commit becomes possible. In such an embodiment,if a validation (i.e., ping test) and/or either part of a two-phasecommit fail (i.e., either the metadata and/or the DOI registration withthe Handle System), then the registration of the DOI will not becomplete and an error will be generated by the IARS indicating an error.Of course, just as with a two-phase commit, depending upon how a userwishes errors to be handled, three-phase commit errors may cause acomplete failure of registration of the DOI(s), and/or alternatively,may still allow portions of any one of the three-phases to complete andsimply alerting the user and/or registration agency of the remainingerrors, which have been specified as noncritical. Such an automatedthree-phase commit registration process is useful for users that requireguaranteed timely publication of a source.

FIG. 16 elaborates on the environment depicted in FIG. 15. FIG. 16highlights that it is contemplated that various registration franchisees16002 may process and accept DOI registrations from publishers 14012 andforward the registration requests to the registration facility 15002.The franchisees may be ISPs, web hosting providers, syndicators,distributors, aggregators, and/or the like. The various franchisees mayextend the reach of the registration facility to obtain additionalpublishers, and provide financial incentives to partner with theregistration facility while building upon the registration facility'sinfrastructure for registration (e.g., providing commissions). In onenon-limiting embodiment, the registration facility will pay a commissionto the franchisees (i.e., a percentage of revenue from every DOIregistration brought to the registration facility by the franchisee). Insuch an embodiment, the franchisee accepts the registration request as a“store front,” but actually passes the registration request back to aregistration facility. The registration facility executes theregistration and is paid directly by the registering user, and uponpayment a commission is paid to the franchisee. In an alternativeembodiment, the “store front” franchisees will accept payments from theregistering users, and will forward payments for registration to theregistration facility. In another non-limiting example embodiment, thefranchisees may license registration technology from the registrationservice, operating substantially independently, but withinformation-sharing or other agreements in place between theregistration service and the franchisee. In an alternative embodiment,the franchisees are employed as outsourced facilities to conduct qualityassurance as is detailed further in the disclosure.

Quality Assurance System Overview

FIG. 17 illustrates a non-limiting example of the DQAS 1701 interactingwith various entities in the validation of a Handle with the HandleSystem. A general overview of validating DOIs involves a DQAS 1701pinging a target location 1718 for a target specified from a DOIdatabase 119. Throughout the disclosure, references made to pinging willbe understood to mean a request for communications where a confirmationof said communication request is expected. Pinging may be as simple as aUnix netstat, ping, spray, traceroutes, and/or the like request(s).However, pinging may also mean more complicated requests such as arequest for data via HTTP, FTP, telephone calls with voice recognition,E-mail confirmation via read receipts, telephony responses, and/or thelike, wherein complex data is returned and may be parsed for validationpurposes. In an alternative embodiment, varying combinations of singleand/or multiple simple ping requests and more complex data requests mayconstitute a single “ping” action, which provides a multitude of metricsregarding the availability of the ping target.

The DQAS validates that a DOI properly resolves to a location containinginformation that is represented by the DOI. For example, if DOI“10.123/abcdefg” represents the information “Moby Dick,” which should befound at location “a.b.com/file”, then when the DQAS 1701 determines tovalidate the DOI “10.123/abcdefg” from the DOI database 119, the DQASwill examine the location “a.b.com/file” and ensure that the location isavailable. In an alternative embodiment, the DQAS may also ensure thatthe location actually contains the associated information “Moby Dick.”

In one non-limiting example validation, a user 1730 may engage the DQAS1701 by submitting and/or establishing a policy to validate a DOI via acommunications network 113. The user may do so by employing a policymanager tool 1731 as will be detailed further in the disclosure in FIG.25 and throughout. The policy manager may set and/or affect policiesthroughout various DQAS components such as a response parser, 1718,feeder 1702, miner 1713, error processor, and/or the like. Typically, apolicy may be established after a DOI has been registered. In analternative embodiment, the policy manager tool is invoked from within aregistration tool. The policy manager tool may be embodied as a web pageor a client application and provide for the validation of DOIs singlyand/or in batches. Upon providing the policy manager tool with theproper entries, the policy manager tool may provide the DQAS (e.g., aregistration agency) with a DOI validation policy for specified DOIs byway of communications network 113. Alternatively, a receiving DQAS 1701may process the DOIs from a DOI database 119 in an automated fashionestablished by a registration agency's policy. Regardless of howpolicies are established, whether by user 1730, policy manager 1731,and/or by a registration agency, a DQAS 1701 will engage in validatingDOIs from a registration agency's database 119.

In one non-limiting example embodiment, a DQAS 1701 comprises a feeder1702, a pinger 1716, a response collector 1717, a response parser 1718,and an error processor 1719. The feeder is further comprised of a miner1713, an enqueue (NQ) feeder 1714, and a dequeue (DQ) feeder 1715. Ofcourse all of the above components may be combined and/or distributed invarious manners as was already discussed in FIG. 1. In one embodiment,the NQ and DQ feeders are separate modules from the miner 1713 anddisposed in communication by way of a communications network 113 tofacilitate scalability. Although not pictured for sake of clarity, allcommunications between components in FIG. 17 and others in thisdisclosure, may be either through direct connections and/or through acommunications network 113; a preferable embodiment will depend upondeployment conditions.

Initially, the miner 1713 makes a request for DOIs to enqueue from theDOI database 119. The DOI database may be maintained by a registrationagency, the Handle System, a mirror, and/or the like. Upon processingthe query request from the miner 1712, the DOI database 119 provides thequery results back to the miner 1713. In an alternative embodiment, theminer receives its apportionment of DOIs from a source database otherthan the Global Handle System, and then the miner compares the recordsit has received from the alternative source with those present in theGlobal Handle System for the same DOIs to ensure that it is verifyingthe records as they appear to public users of DOI system. Next, theminer may find an available NQ feeder to feed the returned query results1714, which are locations of information for various resolutions ofvarious DOIs. The NQ feeder maintains a queue in which it orders DOIresolutions that are to be validated by the DQAS (i.e., a list forreceived NQ messages from the miner). This queue is discussed in greaterdetail in FIG. 18. The NQ feeder then may request statistics regardingDOIs (or various resolutions thereof) that have been enqueued from theDOI database 119. In one embodiment, such statistics may be maintainedin a ping statistics table 119. The requested query results are suppliedback to the NQ feeder 1714 from the DOI database 119. In an alternativeembodiment, these statistics may be obtained by the miner 1713 togetherwith the initial request for DOIs to enqueue. The DOI ping statisticsmay include error rates, times of successful pings, time of failedpings, ranks, and/or the like with regard to any previous qualityassurance validations performed for any given DOI, or any particularresolution thereof. The DOI ping statistics may be used for arranging,ordering, and/or otherwise ranking enqueued DOI resolutions in thefeeder 1702. Such ordered DOI resolutions in turn may be fed to pingers1716.

As the NQ feeder 1714 arranges NQ messages (i.e., DOI resolutions toenqueue for purposes of validation) from the miner and ping statisticsfor the DOIs from the DOI database in its queue, the DQ feeder 1715dequeues ordered NQ messages from the queue. The DQ feeder providesdequeued ping targets to the pinger 1716. When the pinger 1716 obtainsDQd messages (i.e., messages dequeued from the queue), the pinger pingsthe target of the DQd message 1718. In an alternative embodiment, thepinger is passed not particular resolutions of a given DOI, but the DOIitself, and attempts to resolve all locations associated with the DOI asenqueued from a DOI database 119 by a miner. In another alternativeembodiment, the pinger attempts to resolve all locations associated witha DOI as stored in the Handle System and enqueued by miner. If the pingtarget 1718 sends back responses, the ping responses will be obtained bya response collector 1717. A response parser 1718 then obtains thecollected responses from the response collector 1717 and stores thecollected ping responses in the DOI database in a ping statistics table119. The parsed ping responses stored in the ping statistics table 119may contain ping times, latency values, error messages, and/or the like.

As the DOI database and/or ping statistics table 119 collects statisticsand errors associated with DOIs that have been pinged for validity, anerror processor 1719 may make requests for ping response errors from theDOI database 119. As the error processor 1719 obtains query results fromthe DOI database detailing the ping errors, the error processor mayparse the errors, correct the errors, send users reports of the errors,and/or escalate error reports to differing contacts by differingmediums. The error processor will parse, correct, report, and escalateerrors based on a policy established and/or governing for any particularDOI. Any reports and/or escalations by the error processor may in turnbe provided to the user 1730. The user may passively obtain such reportsby way of automated phone calls, E-mail, beeper, and/or the like.

In another embodiment, the user may also actively query for errorreports by way of access managers that allow the user to search forerrors by way of web page via a policy manager and/or the like facility.

Feeder Overview

FIG. 18 illustrates a non-limiting example overview of a feeder and dataflow. A feeder 1712 maintains a priority data structure 1805. Thepriority data structure may be in the form of a database, hash table,queue, sorted (double) linked list, and/or the like (hereinafter“queue”). The queue may be ordered 1801, and contain ping weights 1802for each DOI entry 1803 and any DOI associated information location1804. Each DOI 1803 item 1801 may obtain its ping weight 1802 and/orrank from a composite computed from ping statistics maintained in a DQASdatabase 119 as will be detailed further in FIG. 19. In an alternativeembodiment, the queue may be expanded to have more columns and containactual ping statistics by which the queue is ranked. In this examplequeue 1805, DOIs with the highest ping weights are ordered down towardsthe bottom of the queue. In one embodiment, a higher ping weight evincesa higher priority. In such an embodiment, higher priority potential pingevents are expedited by the feeder to a pinger for ping testing. In thisnon-limiting example, the bottom of the queue is where the higherweighted DOIs are to be dequeued from and supplied to a pinger 1718. NQmessages 1811 are provided to the feeder by a miner (not pictured) froma DQAS database 119. In the example illustrated in the figure, an NQrequest 1811 has a ping weight of “5” and will be inserted as item 13 inthe queue 1805 towards the bottom of the queue. The pinger employs theDQ messages to ping locations across a communications network 113 whereDOI associated information is to be found.

Quality Assurance Feeder

UNI Data Miner

FIG. 19 illustrates one non-limiting example flow diagram of a qualityassurance UNI data miner facility (miner). Optionally, the miner may berun at various intervals as set through a cron job at specified periodicintervals 1901. If the miner runs at specified times, the DQAS willdetermine if the miner's time to run has transpired 1902. If not, theDQAS will keep checking until the specified time has arrived 1902.Alternatively, the miner may run continuously or for only singleiterations.

Also, the miner may be executed on demand, e.g., from a user and/orsystem request. For example, a user that has a need to immediately testa site (e.g., perhaps they have just established an Internet WebPresence and wish to quality test the availability of their contentbefore the public is allowed access), such a user may make a priorityrequest that will be provided to the miner to obtain and test thequality of DOI resolution for the user's content. Furthermore, this ondemand execution may be triggered by various events which are monitoredby the DQAS. In such an embodiment, certain criteria may be monitored bythe DQAS as established in a policy. Criteria may include specifiedpublishers, DOIs, particular types problems, and/or the like. Forexample, a triggering event may be when any DOIs of a particularpublisher prefix are encountered, a miner will engage in qualityassurance testing. In another non-limiting example embodiment, atriggering event may be one where a particular range of DOIs, wheneverencountered by a miner, are ignored and not enqueued for qualityassurance testing. In yet another embodiment, a triggering event may beone where a particular error (e.g., whenever 3 consecutive latencyerrors are detected for any DOI regardless of individual policy) causesthe miner to enqueue a feeder. In essence, the miner may have its owntriggering policies. In one such embodiment, triggering policies may beseparate and overarching policies beyond any individual policiesgenerated by and/or for individual publishers and/or publisher DOIs. Inanother embodiment, the miner may have triggering policies forindividual publishers and/or publisher DOIs. In yet another embodiment,the miner may maintain triggering polices that both overarch individualpolicies, and support individual policies even in combination with eachother. Furthermore, all policies may be dynamically updated.

Upon being instantiated into existence, the miner obtains anapportionment segment for DOIs from a DQAS database 1903. In otherwords, the miner obtains some portion of DOIs requiring validation froma DOI table in a DQAS database 119. The portion may be established bypolicies by the DQAS, and/or the miner. The miner creates a queryrequest for the DQAS database. As there may be multiple instances ofminers making requests of the DQAS, a central DQAS may manage miners soas to avoid repeated requests of the same DOIs, deadlocks, and/or thelike. In such an embodiment, multiple threads, processes, and serversmay all be accessing the DQAS database simultaneously to divide up apotentially large number of DOIs that require validation by the DQAS. Inan alternative embodiment, a single DQAS manages all validation of DOIS.In one embodiment, the miner requests the DOI identifier, associatedresolution location(s), information tag identifier, and/or the like. Inanother embodiment, ping statistics are also requested. The queryrequest may also supply an initial sort for the database query resultsbased on initial criteria 1904.

In one embodiment, the previous computed validation rank is used to sortthe query results so that the highest ranked results are validatedfirst.

Upon obtaining the sorted query results from the DQAS database 1904, theminer iterates for each DOI in the returned query results for thedatabase segment 1905. For each DOI in the returned results 1905, theminer optionally may verify the DOI record with the Handle System 1906.The miner may make an authoritative request and/or a regular request ofthe Handle System. In an alternative embodiment, this additionalverification may be done by the pinger and the results stored in theDQAS database for later mining. Upon iterating for each DOI in theselected database segment 1905, the miner iterates for each resolutionfor each DOI 1907. For example, where an enhanced DOI has two formats(e.g., Format.1B10.123/abcdef; Format.2@10.123/abcdef), each format willhave a resolution location associated with it (e.g., for format 1,www.location.com/spot1; for format 2, www.location2.com/spot2) 1907.Thus for each such resolution location 1907, the miner will obtain pingstatistics for that DOI resolution 1908. In an alternative embodiment,the miner obtains ping statistics with the original query to the DQAS1903. The ping statistics may include information such as errors pingingthe DOI resolution location, the time/date of the last successful pingto the DOI resolution location, number of repeated errors for the DOIresolution location, if the DOI resolution location has ever beenvalidated, composited rank, and/or the like.

Using the ping statistics 1908, the miner determines a new rank for theDOI resolution location 1909. In one non-limiting example embodiment,the new rank (i.e., ping weight) is based on weighted error and pingstatistics 1910. For example:

New Rank = + 1*(Today−LastPingDay)   {The above line provides one rankpoint for each day the DOI   resolution location has not beenvalidated} + 100*(ifNeverVerifiedDOI)   {The above line provides onehundred rank points if the DOI has   never been validated} +10*(ifNewAddressNeverVerified)   {The above line provides 10 rank pointsif the DOI resolution   location has never been validated} +1*(forEachUnitPerX$PaidForVerification)   {The above line provides 1rank point for each purchased rank   point. This is an example where aDQAS operator may charge a   specified amount of money for eachadditional unit of rank priority.} +5*(ifLastPingWasDNSError)*(NumberOfRepeatedDNSErrors/ DNSBatchSize)  {The above line provides 5 rank points for each repeated batch of  DNS errors. A DNS batch size may be specified. A batch size is   aspecified number of occurrences to have transpired for the system   totake notice so that additional rank points will be awarded. If the  last ping resulted in an error, the number of repeated DNS errors  divided by the batch size will result in multiplier for the 5 rank  points.} + 3*(ifLastPingWas404Error)*(NumberOfRepeated404Errors/404BatchSize)   {The above line provides 3 rank points for each repeatedbatch   of HTTP 404 errors. A 404 batch size may be specified. If thelast   ping resulted in an error, the number of repeated 404 errorsdivided   by the batch size will result in multiplier for the 3 rankpoints.} + 1*(ifLastPingWasHighLatency)*(NumberOfRepeatedLatency/LatencyBatchSize)   {The above line provides 1 rank point for eachrepeated batch of   latency errors. A latency batch size may bespecified. If the last ping   resulted in an error, the number ofrepeated latency errors divided   by the batch size will result inmultiplier for the 1 rank points.} +5*(ifErrorRepeated3rdPartyReports)*(NumberOfRepeatedReports/ BatchSize)  {The above line provides 5 rank point for each repeated batch of  3^(rd) party reported errors. A 3^(rd) party reported batch   size maybe specified. If the last ping resulted in an error, the number   ofrepeated 3^(rd) party reported errors divided by the batch size   willresult in multiplier for the 5 rank points.}

The summation of the above will be set equal to the new composited rank.Of course, this is only one ranking scheme, and countless others may beemployed and/or established by way of a policy.

Upon determining a new rank 1909, the miner locates feeders 1911.Feeders may be identified on many criteria such as locating feeders:with the lightest system loads, with the lowest average age of pingpotentials, that are closest to the DOI resolution location, that arefurthest from the DOI resolution location, and/or the like. “Pingpotentials” are DOI resolution locations enqueued in feeders. Apotential ping is one that is enqueued and has not yet been dequeued toa pinger. Such ping potential statistics are maintained by the feedersin a database, log, and/or like data structure. In one embodiment, thefeeders send their current ping potential statistics to miners so thatsuch load balancing decisions may be made by the miners. Uponidentifying an appropriate and/or available feeder, the miner providesNQ message(s) to the identified feeder 1912. Upon enqueuing a DOIresolution location for validation (i.e., pinging) 1912, the miner williterate the next resolution for the current DOI 1907.

When all the multiple resolutions for the current DOI have been iterated1907, the loop ends and the next DOI in the database segment returned bythe DQAS database will be iterated 1905. When all DOIs from the returneddatabase segment have been iterated 1905, the miner will determine if atermination event has occurred 1913. If not, the miner will wait for thenext cron iteration 1901, 1902, and/or continue executing 1903 until atermination event 1913 has been detected at which point execution shallcease 1914.

Engueue Feeder

FIG. 20 illustrates one non-limiting example flow diagram of a qualityassurance enqueue feeder (NQ feeder). Optionally, the NQ feeder may berun at various intervals as set through a cron job at specified periodicintervals 2001. If the NQ feeder runs at specified times, the DQAS willdetermine if the NQ feeder's time to run has transpired 2002. If not,the DQAS will keep checking until the specified time has arrived 2002.Alternatively, the NQ feeder may run continuously or for only singleiterations. Also, the NQ feeder may be executed on demand, e.g., from auser and/or system request.

Upon being instantiated into existence, the NQ feeder obtains a message2003. Typically this message is an NQ message from the miner asdiscussed above in FIG. 19 and throughout. However, in an alternativeembodiment, a DQ message may be obtained from a pinger 2003. Uponobtaining a message, the message is parsed 2004. The message is parsedinto various fields (e.g., type: enqueue request from miner, dequeuerequest from pinger, and/or the like; entry: a DOI, an associatedlocation, metadata, and/or the like; enqueue DOI statistics: pingstatistics, rank, and/or the like; removal: pinger address, and/or thelike; and/or the like. Upon parsing the message 2004, the NQ feederoptionally determines if the message is an NQ or DQ message 2005. Thismay be accomplished by simply parsing out a type field stating if themessage type an enqueue or dequeue request.

If a DQ message is detected 2005, the NQ feeder optionally may determinethe best pinger available 2011. Even though a particular pinger may berequesting a DQ event 2005, the feeder may still determine that a moreappropriate pinger exists that is preferable to the requesting pinger.In one example, a policy established by the DOI owner may require thatonly a specified pinger is to validate the DOI. Alternative embodimentsmay include algorithms based on triangulation of pinger latencies,customer locations, and/or the like considerations. Upon determining thebest pinger, and/or simply identifying the requesting pinger 2011, theNQ feeder will dequeue the next DOI resolution location converting itfrom a potential ping into an actual ping request 2012. Upon having theping request provided to the determined pinger, ping potentialstatistics are logged 2013. In one non-limiting example embodiment, theping potential statistics logged are based on average age of potentialpings, system loads, and/or the like 2013. For example:

NewAvgAge = (  (   (    (TimeDQ−TimeNQofThisDOI)/#DOIsInOldAvg     {Theabove line divides the amount of time the next item to     be dequeuedfrom the NQ feeder has remained a potential     ping candidate by thenumber of potential pings (i.e.,     unpinged DOI location resolutions)that were used to make     the previous average potential ping age forthe NQ feeder}   )   +  OldAvgTime     {The above line adds previousaverage potential ping age for     the NQ feeder to the previous line'sresults}  )/#DOIsNow     {The above line divides the new number ofpotential pings     remaining in the NQ feeder into the previous line'sresults} )

The result of the above computation is the new average age of all pingpotentials on a particular NQ feeder. Of course, this is only one feederstatistic, and countless others may be employed and/or established byway of a policy. Other statistics include system loads, connectionbandwidth, available memory, and/or the like. Such feeder statistics maybe logged, and provided to miners on request so that miners maydetermine which pingers are to be used 2013 as has been discussed inFIG. 19 and throughout. Alternatively, the feeders may use logstatistics, and/or queue length to aid in determining to make requestsof miners for more or fewer NQ messages.

If an NQ message is detected 2005, the NQ feeder optionally maydetermine if the new entry for the queue is already in the list 2006. Inother words, if a DOI resolution location is already enqueued in the NQfeeder's queue 2006, then the old entry in the queue is replaced wherebythe new entry has the latest associated errors, an updated lastsuccessful ping value, etc. from the current DOI record in the DQASdatabase 2007. However, if the NQ request is not already in the list,and/or the duplicate entry has been replaced 2007, then the NQ feederwill obtain ping statistics for that DOI resolution 2008. In analternative embodiment, the NQ feeder obtained ping statistics with theoriginal query to the DQAS 2003. Upon obtaining the ping statistics2008, the NQ feeder determines the NQ request's placement in the queue2009. In one embodiment, the queue takes the form of a stack and FirstIn First Out (FIFO) data flow is employed. In an alternative embodiment,the queue takes the form of a stack and First In Last Out (FILO) dataflow is employed. In an alternative embodiment, the queue takes the formof a hash table, linked list, and/or queue and weighted ranks determinethe order in which items are enqueued and dequeued. In one exampleembodiment, larger weights are sorted down towards the bottom of thequeue and items are dequeued from the bottom of the queue as illustratedin FIG. 18. Upon determining placement of the NQ request 2009, the NQfeeder inserts the NQ request into the queue into the determinedlocation 2010. Upon enqueuing 2010 and/or logging ping potentials 2013,the NQ feeder determines if a termination event has occurred 2014. Ifnot, the NQ feeder waits for the next cron iteration 2001, 2002, and/orcontinue executing 2003 until a termination event 2014 has been detectedat which point execution shall cease 2015.

Dequeue Feeder

FIG. 21 illustrates one non-limiting example flow diagram of a qualityassurance dequeue feeder (DQ feeder). Optionally, the DQ feeder may berun at various intervals as set through a cron job at specified periodicintervals 2101. If the DQ feeder runs at specified times, the DQAS willdetermine if the DQ feeder's time to run has transpired 2102. If not,the DQAS will keep checking until the specified time has arrived 2102.Alternatively, the DQ feeder may run continuously or for only singleiterations. Also, the DQ feeder may be executed on demand, e.g., from auser and/or system request.

Upon being instantiated into existence, the DQ feeder determines thebest pinger available 2103 similarly to NQ feeder determination 2011 ofFIG. 20. Upon determining the best pinger, and/or simply identifying therequesting pinger 2103, the DQ feeder will dequeue the next DOIresolution location converting it from a potential ping into an actualping request 2104. Upon having the ping request provided to thedetermined pinger 2104, ping potential statistics are logged 2105similarly to NQ feeder determination 2013 of FIG. 20. Upon logging pingpotentials 2105, the DQ feeder determines if a termination event hasoccurred 2106. If not, the DQ feeder waits for the next cron iteration2101, 2102, and/or continues executing 2103 until a termination event2106 has been detected at which point execution shall cease 2107.

Pinger & Responder

Pinger

FIG. 22 illustrates one non-limiting example flow diagram of a directoryquality assurance pinger facility (pinger). The pinger 1716 initiallyobtains a next item to ping 2201. The pinger may obtain the next pingitem from a feeder as described above in FIGS. 20 and 21 and throughout.In an alternative embodiment, the pinger may request items to ping froma feeder upon determining that it is available for additional pingingemploying a load statistic log similar to that used between miners andfeeders. The pinger may maintain received ping items 2201 in a cache,queue, and/or the like. Upon obtaining the next ping item 2201, thelocation is pinged 2202. In an alternative embodiment, the pingerobtains ping items with passwords, digital certificates, encryptionkeys, and/or the like security authorization to enable a successful pingof information at what would be an otherwise inaccessible location. Suchsecurity authorization may be provided by way of a policy manager toolas will be described in greater detail in FIG. 25 and throughout. Pingrequests may be initiated over a communications network 113 asasynchronous and/or independent data flow threads to their targets andresponses flow back to response collectors 1722. Upon pinging a location2202, the pinger determines if a termination event has occurred 2203. Ifnot, the pinger continues executing 2201 until a termination event 2203has been detected at which point execution shall cease 2204.

Response Collector

As pingers 1716 ping locations 2202, response collectors 1722 initiallyobtain ping responses 2205. The response collector may maintain receivedping results 2205 in a cache, queue, and/or the like. Upon obtaining theping responses 2205, optionally the response collector may determine ifthe ping results were obtained within a specified time 2208. Thisdetermination may be accomplished by the pinger and response collectorsharing information as discussed in FIG. 1 regarding the DistributedDQAS (e.g., intra-application communication, inter-applicationcommunication, and/or the like). In one embodiment, the pinger maintainsa chronological list of all pinged items, which is used by the responsecollector to check that all pinged items have received ping responses2205 within a specified time 2208. If no ping responses have beenobtained for certain pinged locations 2208, then an error is logged2210. Otherwise, the returned ping responses (and in lieu of theresponses, error log entries) are provided 2207 to a response parser1718. Alternatively, ping responses may be provided directly to a rawping results database table in the DQAS database 119; in such anembodiment, the response parser would continuously mine the DQASdatabase parsing raw ping responses into appropriate fields such as pinglatency, error codes, information tags, and/or the like. Ping resultsmay be provided over a communications network as asynchronous and/orindependent data flow threads to a response parser 1518. Upon providingping and/or error results for parsing 2207, the response collectordetermines if a termination event has occurred 2208. If not, theresponse collector continues executing 2205 until a termination event2208 has been detected at which point execution shall cease 2209.

Response Parser

As response collectors 1722 provide ping results 2207, response parsers1718 initially obtain ping results 2210. The response parser maymaintain received ping results 2210 in a cache, queue, and/or the like.Upon obtaining the ping results 2210, the response parser parses theping results 2211. The response parser parses the raw ping results intoappropriate fields such as: errors: DNS lookup, host, HTTP 404's,latency, time outs, and/or the like; information tags (for informationwith embedded tags validating an association between the DOI and theinformation), and/or the like); and/or the like 2211. Upon parsing theping results 2211, the parsed ping results are stored 2212 in a pingstatistics database table in the DQAS database 119. Upon storing theparsed ping results 2212, the response parser determines if atermination event has occurred 2213. If not, the response parsercontinues executing 2210 until a termination event 2213 has beendetected at which point execution shall cease 2214.

Error Processor

FIG. 23 illustrates one non-limiting example flow diagram of a qualityassurance error processor (error processor). Optionally, the errorprocessor may be run at various intervals as set through a cron job atspecified periodic intervals 2301. If the error processor runs atspecified times, the DQAS will determine if the error processor's timeto run has transpired 2302. If not, the DQAS will keep checking untilthe specified time has arrived 2302. Alternatively, the error processormay run continuously or for only single iterations. Also, the errorprocessor may be executed on demand, e.g., from a user and/or systemrequest.

Upon being instantiated into existence, the error processor obtains anapportionment segment for DOIs from a DQAS database 2303. In otherwords, the error processor obtains some portion of DOIs requiringvalidation from an error table in a DQAS database 119. The portion maybe established by policies by the DQAS, and/or the error processor. Theerror processor creates a query request for the DQAS database. As theremay be multiple instances of error processors making requests of theDQAS, a central DQAS may manage error processor so as to avoid repeatedrequests of the same DOIs, deadlocks, and/or the like. In such anembodiment, multiple threads, processes, and servers may all beaccessing the DQAS database simultaneously to divide up a potentiallylarge number of ping responses that require parsing by the errorprocessor. In an alternative embodiment, a single DQAS manages allvalidation of DOIs. In an alternative embodiment, a single DQAS managesall validation of DOIs. In one embodiment, the error processor requeststhe DOI identifier, associated resolution location, information tagidentifier, and/or the like. In another embodiment, ping statistics arealso requested. The query request may also supply an initial sort forthe database query results based on initial criteria 2304. In oneembodiment, the previous computed validation rank is used to sort thequery results so that the highest ranked results are validated first.Another embodiment includes a sort order by pinger, then by host, thenby contact, then by error type, then by DOI, and then by DOI location2304.

Upon obtaining the sorted query results from the DQAS database 2304, theerror processor determines if bad pinger is a common error 2305. Thismay be determined by a sort order wherein results from the error table119 have repeated entries for the same pinger, while the sameresolutions generate no errors or different errors when queried fromother pingers. Numerous repeated entries for a single pinger mayindicate a pinger error, and warrant sending an error report to theDQAS′ administrator 2306. In one embodiment, when pinger errors aredetermined 2305, all returned pinger errors 2304 are flagged with a badpinger error and such errors are not included in error reports for usersso as to allow DQAS administrators to fix any pinger errors withoutunduly disturbing DOI owners with false alarms.

Upon sending an error report to an administrator 2306 or if no badpingers are detected 2305, optionally the error processor determines ifa bad DOI resolution location server is a common error 2307. This may bedetermined by a sort order wherein results from the error table 119 haverepeated entries for the same server hosting information to which DOIsresolve. Numerous repeated entries for a single host may indicate a hosterror, rather than an error in the DOI records, and warrant sending anerror report to the host's administrator 2308. In one embodiment, when ahost error is determined 2307, all returned host errors 2304 are flaggedwith a bad host error and such errors are not included in error reportsfor users so as to allow host administrators to fix any host errors.

Upon sending an error report to an administrator 2306, 2308 or if no badpingers or hosts are detected 2305, 2307, the error processor iteratesfor each contact in the returned query results for the database segment2309. In alternative embodiments, rather than iterating by contact, theerror processor may iterate by publisher and/or other identifyingfields. Contact information may be obtained through contact metadata ina metadata table in a DQAS database 119 and/or from a policy manager1731 of FIG. 17. Contact information identifies a person and/or entityto contact with regard to any given DOI and/or publisher. For eachcontact in the returned results 2309, the error processor may create anerror report 2309. In one embodiment, initially creating the report mayinvolve simply allocating space in memory for an XML file with the titleof the error report, contact metadata information, and/or the like.

Upon initially instantiating an error report for a contact 2310, theerror processor iterates for each error type for each contact 2311. Thusfor each such error type 2311, the error processor will create an errortype entry 2314 in each error report 2310 for each contact 2309. Uponcreating an error type entry in the report 2314, the error processoriterates for each location that a DOI references 2315. Thus for eachlocation that a DOI references 2315, the error processor will create anerror location entry 2316 in each error type entry 2314 in each errorreport 2310 for each contact 2309. In one embodiment, the error locationentry may include the date and time of the error, the pinger responsiblefor determining the error, and/or the like. Upon creating an errorlocation entry 2316 in the contact's error report, the error processorcalculates the number of errors experienced by the currently iteratedlocation that a DOI references 2317 by adding “1” to the previous errorcount for the location that a DOI references. Upon calculating thenumber of errors experienced by the currently iterated location 2317,the error processor will iterate the next location that a DOI referencesfor the current DOI 2315.

When all the locations have been iterated 2315, the loop ends and theerror processor employs a policy for that DOI 2399. The policy mayestablish how error correction, notification, reporting escalation,and/or the like are to take place for each DOI 2315. Upon executing thepolicy for all the locations of a DOI 2315, 2399 (continuing in greaterdetail in FIG. 24), flow returns from the executed policy 2388. Anysummation counts are also conducted at the end of the DOI loop 2315.Upon returning from executing any reporting policies 2388, the DOI loopends and the next error type entry is iterated 2311. When all the errortypes have been iterated 2311, the loop ends and the error processordetermines if a flag to send the generated error report(SendErrorReportFlag) has been set to “Yes” 2312. If so, the finishederror report will be sent to the contact 2313. If the flag to send areport has not been set to “Yes,” then the next contact is iterated2309. Any summation counts are also conducted at the end of the errortype loop 2311 and are provided into the error report before it is sent.When all the contacts have been iterated 2309, the contact loop ends andthe error processor will determine if a termination event has occurred2318. If not, the miner will wait for the next cron iteration 2301,2302, and/or continue executing 2303 until a termination event 2318 hasbeen detected at which point execution shall cease 2319.

Example DQAS Policy

FIG. 24 illustrates one non-limiting example flow diagram of a qualityassurance error report policy (policy). Initially, the policy is called2499 by error processor 1719 of FIG. 17, 2399 of FIG. 23. The policy maybe integrated into the error processor, obtained from a policy table ina DQAS database 119. A policy manager 1731 may be used to create variouspolicies. After calling the policy 2499, the error processor determinesif the current number of errors calculated by the error processor 2317of FIG. 23 is less than 12401, i.e., if there are no errors. If thereare no errors 2401, then SendErrorReportFlag is set to equal “No” 2402and the policy terminates 2488 with execution flow returning to thepoint of call 2388 of FIG. 23. If there are errors 2401, thenSendErrorReportFlag is set to equal “Yes” 2403.

Next, the error processor determines if the current number of errorscalculated by the error processor 2317 of FIG. 23 is greater than 12401,i.e., if there are at least two errors. If there is only one error 2404,i.e., the current number of errors is not greater than one, the policyterminates 2488 with execution flow returning to the point of call 2388of FIG. 23. If there is more than one error 2404, then error processordetermines if the current error type 2311 of FIG. 23 is verified to bean HTTP 404 and/or DNS lookup error 2405. If it is a verified 404 and/orDNS error 2405, then the error processor determines if a backupresolution location exists 2406.

In one embodiment, an enhanced DOI may have backup locations storinginformation represented by its DOI. For example, where an enhanced DOIhas two backups (e.g., Backup.1@10.123/abcdef; Backup.2@10.123/abcdef),each format will have a resolution location associated with it (e.g.,respectively: for backup 1, www.location.com/backup1; for backup 2,www.location2.com/backup2). If a backup does exist 2406, the errorprocessor effects a change in the resolution of the current DOI location2315 of FIG. 23 to a backup location. For example, wherein a primaryDOI's (10.123/abcdef) normal location for information(www.location.com/data) is reported as unavailable for a second time bythe error processor, the policy 2407 effects a new association; namely,the primary DOI's backup location is temporarily set to resolve for theprimary DOI (e.g., 10.123/abcdef is set to resolve towww.location.com/backup1). This temporary change of resolution isachieved by effecting a reference update in the Handle System by theregistration agency.

However, if no backup enhanced DOI exists 2406, or there is a latencyerror 2409, or there is no tag error 2410, then the DOI's resolution ischanged to a proxy error page 2408 as provided by the DQAS. The errorpage 2408 may be a web page maintained at the DQAS and/or registrationagency. The error page may provide a notice: that the requested DOI isexperiencing technical difficulties, that the DOI may be temporarilyunavailable, of a link to the location the user wishes to accessinforming the user of potential problems, of a web page automaticallyattempting to redirect to the proper location, of web page mentioningthat the publisher is no longer available and the last known contactinformation for the DOI, and/or the like 2413. If the current error isnot an unidentified tag error 2410, then all other error types will behandled by the proxy error page as a catchall 2408. However, if thecurrent error is not a tag error 2410, then the error processor mayobtain DOI metadata for the current DOI location and compare themetadata to the information at the location referenced by the DOI. A tagerror would occur when a user requested that not only should the errorprocessor determine that the current location referenced by the DOI beavailable, but that it also actually store the proper associatedinformation. In an alternative embodiment, the error processor looks fora tag with the DOI number embedded into the information and/or documentfor comparison. Upon comparing the metadata and/or tags, the errorprocessor determines a confidence rating of how likely it is that theinformation at the location referenced by a DOI is the correctinformation. If the error processor is not more than 50% confident 2412,then the DOI's resolution is changed to a proxy error page 2408.However, if the error processor is more than 50% confident 2412, thenthe error processor generates a DOI verify tag for the information,which will be sent with any error report and instruction for adding thegenerated tag 2413. Generating the DOI verify tag for the informationmay be accomplished by simply informing the user to embed an XML tagwith field called DOI and an entry having the content's associated DOI2413. In an alternative embodiment, the error processor computes a hash,checksum, key, and/or the like based upon the target information's file2413. In one embodiment, the instruction for adding such a tag are tosimply append it to the end of the file 2413. In one embodiment, theinstructions are sent as part of the error report 2413.

In yet another alternative embodiment, a tag is generated whenregistering a DOI via a registration tool. In such an embodiment, uponhaving securely registered a DOI with the handle system, the DOI is thenobtained and embedded as a tag in the actual content. In such anembodiment, the registration tool would append a tag code to a localcopy of the source, e.g., creating a file with an XML tag containing theDOI such as “<SOURCE TAG VALIDATOR>10.123/abcdefg</SOURCE TAGVALIDATOR>” and using a Unix cat operation to append the tag to thesource. Thereafter, the registration tool would effect and propagate thenew modified source to all resolution locations for the DOI, thusproviding a tagged version of the source that facilitates validation ofsource availability. In yet another alternative embodiment, the taggedsource may be automatically hosted by a storage facility. Such automatichosting may be desired if the source has not yet been made available inany location, and/or if a user wishes the source to be made available innew locations.

Upon changing DOI location resolution 2407, changing resolution to aproxy error page 2408, and/or generating DOI verify tags for actualcontent 2413, the error processor determines if there is more than twoerrors 2414, i.e., there are 3 or more errors, then notification isescalated to auto dial a contact by phone 2415. The contact may bedialed upon looking up contact information from a metadata data in aDQAS database. Dial out may be achieved by an answering machine enabledtelephony modem, and/or the like. If there are not greater than 2 errors2414, then the policy terminates 2488 with execution flow returning tothe point of call 2388 of FIG. 23. Upon calling the phone contact 2415,the error processor checks to see if this is the third latency error2416. If there are greater than 2 errors 2414 for latency 2416, then theerror manager changes the resolution of the DOI to point to a latencyproxy error page 2417 similar to the catchall proxy error page 2408.However, this latency proxy error page allows a user to enter an emailaddress into an E-mail field, and the user will be E-mailed his/herrequested DOI referenced content 2417.

Upon changing DOI location resolution 2417, the error processordetermines if there is more than three errors 2418, i.e., there are 4 ormore errors, then notification is escalated to a DQAS agent who in turncan track down a human contact to effect a proper resolution of the DOI2419. If there are not greater than 3 errors 2418 or the DQAS agent hasbeen contacted 2419, then the policy terminates 2488 with execution flowreturning to the point of call 2388 of FIG. 23.

Policy Manager

FIG. 25 illustrates a non-limiting example of a policy manager tool. Apolicy manager tool may be embodied in a web page 2575 to be executedthrough a web browser. The policy manager tool may employ standardgraphical user interface widgets such as text boxes, pop-up menus,and/or the like. The widgets are configured to respond to usercontrolled cursor selections 2532, and/or text insertion tools 2533. Itis understood that various user interface widgets may be used tosubstitute for the functionality of any example employed widgets herein.For example, the pop-up text entry menu 2504 may be replaced with aplain text field, and/or the like, herein and throughout the disclosure.

In one example embodiment, a user will query a database 119 to obtain apolicy for a desired DOI 2501. In one embodiment, the policy may beinherited 2502 by using a policy generic to a publisher prefix 2521, atemplate policy saved in a profile 2522, or a custom policy 2525 that isspecified in the policy manager 2575.

When specifying a custom policy 2525, a user may specify multiplecontacts who will be in receipt of notifications from the DQAS 2503,2507. In the depicted embodiment, two contacts are provided, butalternative embodiments are envisioned with fewer or more contacts. Thecontacts may be specified by name, E-mail, telephone numbers, and/or thelike. In alternative embodiments, addresses, faxes, pagers, and/or thelike may be added to the contact information 2503, 2507 for notificationpurposes.

For each contact, a user may specify a mode by selecting a check box2555, a notification priority 2556 by selecting choices from a pop-upmenu, and a time limit also by way of pop-up menu 2557, all of whichestablish a policy of notification for that contact. Selecting a modecheck box determines if the contact will be notified by a certain modesuch as by E-mail 2504, by telephone at work 2505, by pager 2506, and/orthe like. Selecting a notification priority option 2556 allows a user tospecify if they wish to be notified in instances such as: on the firsterror reported, anytime an error occurs weekdays from 8 AM to 5 PM, ifthere is no E-mail response received by the DQAS within one hour of theinitial E-mail notification, if there is no E-mail response received bythe DQAS within three hours of the initial E-mail notification, and/orthe like 2517. Also, time constraints 2557 on the notification 2556,2555 may be established by the user. Notifications may be issued 24hours a day, or weekdays from 8 AM to 5 PM. Of course in alternativeembodiments, these constraints may be varied allowing specification ofindividual seconds, minutes, hours, days, weeks, months, years, and/orthe like time limits. Similarly, notification priorities may be variedas well as modes.

It is important to note, that in addition to a tiering of notificationmodes (i.e., E-mail, facsimile, pager, telephone, voice message, humanagent contact, etc.), which may be specified in any escalation order,DQAS agents may be notified to intercede and manage error reports onbehalf of DOI owners. In such an embodiment, DQAS agents (e.g., systemoperators, administrators, and/or the like) receive reports and wouldtroubleshoot the cause of error. In one embodiment, such agents wouldhave access to the DOI owner's DOI referenced content, and may proceedto attempt to remedy problems regarding accessibility independently ofand/or under the supervision of the DOI owner. Upon administering theproblem, DQAS agents would provide a DOI owner with a status reportingservice activity. Such delegated administration may be billed for oncontract terms, and/or per incident. Such delegation would also save DOIowners from a deluge of error reports. Of course, DOI owners also mayrequest cessation of error reports for any specified period.

Such a delegated administration system may be enabled by aninformation-sharing system such as Lotus Notes and/or othercommercially-available and/or custom-developed software with statusnotification being routed thereto. Each status notification may be givena job ticket number for billing and administrative purposes. In one suchembodiment, the job ticket number may itself be a DOI. In an alternativeembodiment, the status notification may also include contactinformation, which may be obtained from a metadata database, and/or thelike.

The user may also specify that summary reports 2510 be generated withincertain time limits 2557, 2511. Summary reports may be made once daily(seven days a week) 2511, once weekly on specified days, and almost anyother conceived interval. Upon entry of the contact and policyinformation for a specified contact and DOI, a user may effect thestorage of the policy into a DQAS database 119 by engaging a facility toadd the contact information (e.g., an add contact button 2512), whichmay result in the policy manager tool transmitting the policy to theDQAS database for storage.

In one embodiment, the policy manager 2575 provides the ability to setquality assurance preferences 2585 such as subscription controls 2586,ping preferences 2587, access to error tracking 2588, and/or the like.Adding subscription access and method controls 2586 allows the user tospecify if the DOI referenced location being tested is: informationavailable to the public without security authorization 2508; to belimited to testing from a specified pinger with a specific IP address toping the host of the DOI referenced information 2509; requiring ausername and password that will be used to issue a POST command to allowa pinger access to information requiring security authorization 2513;requiring some other file based security authorization through cookieaccess whereby a user can specify a cookie coptaining securityauthorization such as username, password, digital certificate,encryption keys, and/or the like 2514; and/or the like. The “Post CookieData . . . ” facility once engaged brings up a file selection facilityallowing the user to identify the requisite security authorizationinformation.

It should be noted that a DOI owner may wish to validate access to a DOIsource with and/or without security authorization. For example, a DOIowner may operate a pay-for-content operation and may wish to ping testthe content to make sure a proper inaccessible error is returned; oralternatively, the DOI owner may wish non-paid-for access to resolve toanother location, such as a URL requesting payment for access. In analternative example, the DOI owner may want pay-for-content to be testedand validated as being accessible, and thus the DQAS will have toprovide a password and/or other security authorization to properlyvalidate the content. In one embodiment, the DQAS may charge varyingamounts for such security authorized validation, e.g., changing more forsecurity authorized validation.

In one embodiment, the policy manager allows the user to set pingpreferences 2587 by adjusting the interval of pinging and the geographiclocation of pingers to be used 2515. Also, the policy manager allows theuser to access error tracking 2588 by selecting to manually accessvarious error logs from the DQAS 2516 (e.g., allowing the user to haveweb access to trouble databases, constructing a policy that generatesXML based error logs, and/or the like 2516).

It should be understood that the above description is onlyrepresentative of illustrative embodiments. For the convenience of thereader, the above descriptions have focused on a representative sampleof all possible embodiments, a sample that teaches the principles of theinvention. The description has not attempted to exhaustively enumerateall possible variations. That alternate embodiments may not have beenpresented for a specific portion of the invention or that furtherundescribed alternate embodiments may be available for a portion is notto be considered a disclaimer of those alternate embodiments. It will beappreciated that many of those undescribed embodiments incorporate thesame principles of the invention and others are equivalent. Thus, it isto be understood that the embodiments and variations shown and describedherein are merely illustrative of the principles of this invention andthat various modifications may be implemented without departing from thescope and spirit of the invention.

1. A method of using a computer for validating location addresses,comprising: obtaining a unique, persistent, and universal nameidentifier for a source; obtaining location addresses of the source forresolution with the unique, persistent, and universal name identifier;validating that the location addresses are accessible.
 2. The method ofclaim 1, wherein a triggering event causes validation.
 3. The method ofclaim 1, wherein the location addresses and unique, persistent, anduniversal name identifier are received from a database for resolvingunique, persistent, and universal name identifiers with locationaddresses of associated sources.
 4. The method of claim 1, furthercomprising: resolving the location addresses of the source forvalidating the unique, persistent, and universal name identifier with adatabase for resolving unique, persistent, and universal nameidentifiers with location addresses of associated sources, whereinvalidation that the location addresses are accessible includes comparingthe obtained location addresses with location addresses resolved by thepublic database.
 5. The method of claim 1, further comprising:validating the source at location addresses.
 6. The method of claim 5,wherein source validation is based on recognizing a tagging codeembedded in the source.
 7. The method of claim 6, wherein the taggingcode is the unique, persistent, and universal name identifier.
 8. Themethod of claim 6, wherein the tagging code is a security authorizationmechanism.
 9. The method of claim 1, further comprising: validating thatthe source at location addresses is accessible.
 10. The method of claim8 wherein security authorization is provided to access the source. 11.The method of claim 1, further comprising: providing status notificationregarding validity.
 12. The method of claim 11, wherein the statusnotification is regarding the validity of the unique, persistent, anduniversal name identifier.
 13. The method of claim 11, wherein thestatus notification is regarding the validity of the location addresses.14. The method of claim 11, wherein the status notification is regardingthe validity of the source.
 15. The method of claim 11, wherein thestatus notification is in E-mail.
 16. The method of claim 11, whereinthe status notification is provided to a delegated agent for erroradministration.
 17. The method of claim 11, wherein the statusnotification is governed by policies.
 18. The method of claim 17,wherein the policies specify escalated notifications respective toescalated validity error status.
 19. The method of claim 1, whereinvalidating is achieved by pinging the location addresses.
 20. The methodof claim 19, wherein pinging includes security authorization tofacilitate access to secured sources.
 21. A method of using a computerfor tagging a source, comprising: determining a tagging code, whereinthe tagging code, once recognized, establishes the validity of a source;tagging a source with the tagging code, wherein the source is resolvedto by a unique, persistent, and universal name identifier.
 22. Themethod of claim 21, further comprising: validating the source byrecognizing the tagging code embedded in the source.
 23. The method ofclaim 22, wherein a triggering event causes validation.
 24. The methodof claim 21, further comprising: validating that the location addressesare accessible.
 25. The method of claim 21, wherein source taggingoccurs during the registration of a unique, persistent, and universalname identifier.
 26. The method of claim 21, wherein source taggingoccurs during the creation of the source.
 27. The method of claim 21,wherein source tagging occurs within a content authoring tool.
 28. Themethod of claim 21, wherein the tagging code is the unique, persistent,and universal name identifier.
 29. The method of claim 21, wherein thetagging code is a security authorization mechanism.
 30. A method ofusing a computer to effect registration, comprising: determining atagging code, wherein the tagging code, once recognized, establishes thevalidity of a source; tagging a source with the tagging code; generatinga unique, persistent, and universal name identifier associated with thesource; receiving an address for a location for the source; effectingthe registration of the unique, persistent, and universal nameidentifier with the address associated to the location of the source ina database for resolving unique, persistent, and universal nameidentifiers and locations of associated sources, wherein the unique,persistent, and universal name identifier is unique in the database. 31.The method of claim 30, wherein the tagging code is the unique,persistent, and universal name identifier.
 32. The method of claim 30,wherein the tagging code is a security authorization mechanism.
 33. Themethod of claim 30, further comprising: validating that the locationaddresses are accessible.
 34. The method of claim 33, wherein atriggering event causes validation.
 35. The method of claim 30, furthercomprising: validating the source by recognizing the tagging codeembedded in the source.
 36. A method of using a computer to effectregistration, comprising: determining a tagging code, wherein thetagging code, once recognized, establishes the validity of a source;tagging a source with the tagging code; allocating space in a storagefacility for the source; making a location of the allocated spaceaddressable and accessible over a communications network; storing thesource to the allocated space; generating a unique, persistent, anduniversal name identifier associated with the source; effecting theregistration of the unique, persistent, and universal name identifierwith an address associated to the location where the source is stored ina database for resolving unique, persistent, and universal nameidentifiers and locations of associated sources, wherein the unique,persistent, and universal name identifier is unique in the database. 37.The method of claim 36, wherein the tagging code is the unique,persistent, and universal name identifier.
 38. The method of claim 36,wherein the tagging code is a security authorization mechanism.
 39. Themethod of claim 36, further comprising: validating the source byrecognizing the tagging code embedded in the source.
 40. The method ofclaim 39, wherein a triggering event causes validation.
 41. The methodof claim 36, further comprising: validating that the location addressesare accessible.
 42. (canceled)
 43. (canceled)
 44. A system for using acomputer for validating location addresses, comprising: means to obtaina unique, persistent, and universal name identifier for a source; meansto obtain location addresses of the source for resolution with theunique, persistent, and universal name identifier; means to validatethat the location addresses are accessible.
 45. The system of claim 44,wherein a triggering event causes validation.
 46. The system of claim44, wherein the location addresses and unique, persistent, and universalname identifier are received from a database for resolving unique,persistent, and universal name identifiers with location addresses ofassociated sources.
 47. The system of claim 44, further comprising:means to resolve the location addresses of the source for validating theunique, persistent, and universal name identifier with a database forresolving unique, persistent, and universal name identifiers withlocation addresses of associated sources, wherein validation that thelocation addresses are accessible includes comparing the obtainedlocation addresses with location addresses resolved by the publicdatabase.
 48. The system of claim 44, further comprising: means tovalidate the source at location addresses.
 49. The system of claim 48,wherein source validation is based on recognizing a tagging codeembedded in the source.
 50. The system of claim 49, wherein the taggingcode is the unique, persistent, and universal name identifier.
 51. Thesystem of claim 49, wherein the tagging code is a security authorizationmechanism.
 52. The system of claim 51 wherein security authorization isprovided to access the source.
 53. The system of claim 44, furthercomprising: means to validate that the source at location addresses isaccessible.
 54. The system of claim 44, further comprising: means toprovide status notification regarding validity.
 55. The system of claim54, wherein the status notification is regarding the validity of theunique, persistent, and universal name identifier.
 56. The system ofclaim 54, wherein the status notification is regarding the validity ofthe location addresses.
 57. The system of claim 54, wherein the statusnotification is regarding the validity of the source.
 58. The system ofclaim 54, wherein the status notification is in E-mail.
 59. The systemof claim 54, wherein the status notification is provided to a delegatedagent for error administration.
 60. The system of claim 54, wherein thestatus notification is governed by policies.
 61. The system of claim 60,wherein the policies specify escalated notifications respective toescalated validity error status.
 62. The system of claim 44, whereinvalidating is achieved by pinging the location addresses.
 63. The systemof claim 62, wherein pinging includes security authorization tofacilitate access to secured sources.
 64. A system for using a computerfor tagging a source, comprising: means to determine a tagging code,wherein the tagging code, once recognized, establishes the validity of asource; means to tag a source with the tagging code, wherein the sourceis resolved to by a unique, persistent, and universal name identifier.65. The system of claim 64, further comprising: means to validate thesource by recognizing the tagging code embedded in the source.
 66. Thesystem of claim 65, wherein a triggering event causes validation. 67.The system of claim 64, further comprising: means to validate that thelocation addresses are accessible.
 68. The system of claim 64, whereinsource tagging occurs during the registration of a unique, persistent,and universal name identifier.
 69. The system of claim 64, whereinsource tagging occurs during the creation of the source.
 70. The systemof claim 64, wherein source tagging occurs within a content authoringtool.
 71. The system of claim 64, wherein the tagging code is theunique, persistent, and universal name identifier.
 72. The system ofclaim 64, wherein the tagging code is a security authorizationmechanism.
 73. A system for using a computer to effect registration,comprising: means to determine a tagging code, wherein the tagging code,once recognized, establishes the validity of a source; means to tag asource with the tagging code; means to generate a unique, persistent,and universal name identifier associated with the source; means toreceive an address for a location for the source; means to effect theregistration of the unique, persistent, and universal name identifierwith the address associated to the location of the source in a databasefor resolving unique, persistent, and universal name identifiers andlocations of associated sources, wherein the unique, persistent, anduniversal name identifier is unique in the database.
 74. The system ofclaim 73, wherein the tagging code is the unique, persistent, anduniversal name identifier.
 75. The system of claim 73, wherein thetagging code is a security authorization mechanism.
 76. The system ofclaim 73, further comprising: means to validate that the locationaddresses are accessible.
 77. The system of claim 76, wherein atriggering event causes validation.
 78. The system of claim 73, furthercomprising: means to validate the source by recognizing the tagging codeembedded in the source.
 79. A system for using a computer to effectregistration, comprising: means to determine a tagging code, wherein thetagging code, once recognized, establishes the validity of a source;means to tag a source with the tagging code; means to allocate space ina storage facility for the source; means to make a location of theallocated space addressable and accessible over a communicationsnetwork; means to store the source to the allocated space; means togenerate a unique, persistent, and universal name identifier associatedwith the source; means to effect the registration of the unique,persistent, and universal name identifier with an address associated tothe location where the source is stored in a database for resolvingunique, persistent, and universal name identifiers and locations ofassociated sources, wherein the unique, persistent, and universal nameidentifier is unique in the database.
 80. The system of claim 79,wherein the tagging code is the unique, persistent, and universal nameidentifier.
 81. The system of claim 79, wherein the tagging code is asecurity authorization mechanism.
 82. The system of claim 79, furthercomprising: means to validate the source by recognizing the tagging codeembedded in the source.
 83. The system of claim 82, wherein a triggeringevent causes validation.
 84. The system of claim 79, further comprising:means to validate that the location addresses are accessible. 85.(canceled)
 86. (canceled)
 87. A program stored on a medium readable by aprocessor, the program for validating location addresses, comprising: amodule to obtain a unique, persistent, and universal name identifier fora source; a module to obtain location addresses of the source forresolution with the unique, persistent, and universal name identifier; amodule to validate that the location addresses are accessible.
 88. Themedium of claim 87, wherein a triggering event causes validation. 89.The medium of claim 87, wherein the location addresses and unique,persistent, and universal name identifier are received from a databasefor resolving unique, persistent, and universal name identifiers withlocation addresses of associated sources.
 90. The medium of claim 87,further comprising: a module to resolve the location addresses of thesource for validating the unique, persistent, and universal nameidentifier with a database for resolving unique, persistent, anduniversal name identifiers with location addresses of associatedsources, wherein validation that the location addresses are accessibleincludes comparing the obtained location addresses with locationaddresses resolved by the public database.
 91. The medium of claim 87,further comprising: a module to validate the source at locationaddresses.
 92. The medium of claim 91, wherein source validation isbased on recognizing a tagging code embedded in the source.
 93. Themedium of claim 92, wherein the tagging code is the unique, persistent,and universal name identifier.
 94. The medium of claim 92, wherein thetagging code is a security authorization mechanism.
 95. The medium ofclaim 94 wherein security authorization is provided to access thesource.
 96. The medium of claim 87, further comprising: a module tovalidate that the source at location addresses is accessible.
 97. Themedium of claim 87, further comprising: a module to provide statusnotification regarding validity.
 98. The medium of claim 97, wherein thestatus notification is regarding the validity of the unique, persistent,and universal name identifier.
 99. The medium of claim 97, wherein thestatus notification is regarding the validity of the location addresses.100. The medium of claim 97, wherein the status notification isregarding the validity of the source.
 101. The medium of claim 97,wherein the status notification is in E-mail.
 102. The medium of claim97, wherein the status notification is provided to a delegated agent forerror administration.
 103. The medium of claim 97, wherein the statusnotification is governed by policies.
 104. The medium of claim 103,wherein the policies specify escalated notifications respective toescalated validity error status.
 105. The medium of claim 87, whereinvalidating is achieved by pinging the location addresses.
 106. Themedium of claim 105, wherein pinging includes security authorization tofacilitate access to secured sources.
 107. A program stored on a mediumreadable by a processor, the program for tagging a source, comprising: amodule to determine a tagging code, wherein the tagging code, oncerecognized, establishes the validity of a source; a module to tag asource with the tagging code, wherein the source is resolved to by aunique, persistent, and universal name identifier.
 108. The medium ofclaim 107, further comprising: a module to validate the source byrecognizing the tagging code embedded in the source.
 109. The medium ofclaim 108, wherein a triggering event causes validation.
 110. The mediumof claim 107, further comprising: a module to validate that the locationaddresses are accessible.
 111. The medium of claim 107, wherein sourcetagging occurs during the registration of a unique, persistent, anduniversal name identifier.
 112. The medium of claim 107, wherein sourcetagging occurs during the creation of the source.
 113. The medium ofclaim 107, wherein source tagging occurs within a content authoringtool.
 114. The medium of claim 107, wherein the tagging code is theunique, persistent, and universal name identifier.
 115. The medium ofclaim 107, wherein the tagging code is a security authorizationmechanism.
 116. A program stored on a medium readable by a processor,the program to effect registration, comprising: a module to determine atagging code, wherein the tagging code, once recognized, establishes thevalidity of a source; a module to tag a source with the tagging code; amodule to generate a unique, persistent, and universal name identifierassociated with the source; a module to receive an address for alocation for the source; a module to effect the registration of theunique, persistent, and universal name identifier with the addressassociated to the location of the source in a database for resolvingunique, persistent, and universal name identifiers and locations ofassociated sources, wherein the unique, persistent, and universal nameidentifier is unique in the database.
 117. The medium of claim 116,wherein the tagging code is the unique, persistent, and universal nameidentifier.
 118. The medium of claim 116, wherein the tagging code is asecurity authorization mechanism.
 119. The medium of claim 116, furthercomprising: a module to validate that the location addresses areaccessible.
 120. The medium of claim 119, wherein a triggering eventcauses validation.
 121. The medium of claim 116, further comprising: amodule to validate the source by recognizing the tagging code embeddedin the source.
 122. A program stored on a medium readable by aprocessor, the program to effect registration, comprising: a module todetermine a tagging code, wherein the tagging code, once recognized,establishes the validity of a source; a module to tag a source with thetagging code; a module to allocate space in a storage facility for thesource; a module to make a location of the allocated space addressableand accessible over a communications network; a module to store thesource to the allocated space; a module to generate a unique,persistent, and universal name identifier associated with the source; amodule to effect the registration of the unique, persistent, anduniversal name identifier with an address associated to the locationwhere the source is stored in a database for resolving unique,persistent, and universal name identifiers and locations of associatedsources, wherein the unique, persistent, and universal name identifieris unique in the database.
 123. The medium of claim 122, wherein thetagging code is the unique, persistent, and universal name identifier.124. The medium of claim 122, wherein the tagging code is a securityauthorization mechanism.
 125. The medium of claim 122, furthercomprising: a module to validate the source by recognizing the taggingcode embedded in the source.
 126. The medium of claim 125, wherein atriggering event causes validation.
 127. The medium of claim 122,further comprising: a module to validate that the location addresses areaccessible.
 128. (canceled)
 129. (canceled)
 130. An apparatus forvalidating location addresses, comprising: a processor; a memory,communicatively connected to the processor; a program, stored in thememory, including, a module to obtain a unique, persistent, anduniversal name identifier for a source; a module to obtain locationaddresses of the source for resolution with the unique, persistent, anduniversal name identifier; a module to validate that the locationaddresses are accessible.
 131. The apparatus of claim 130, wherein atriggering event causes validation.
 132. The apparatus of claim 130,wherein the location addresses and unique, persistent, and universalname identifier are received from a database for resolving unique,persistent, and universal name identifiers with location addresses ofassociated sources.
 133. The apparatus of claim 130, further comprising:a module to resolve the location addresses of the source for validatingthe unique, persistent, and universal name identifier with a databasefor resolving unique, persistent, and universal name identifiers withlocation addresses of associated sources, wherein validation that thelocation addresses are accessible includes comparing the obtainedlocation addresses with location addresses resolved by the publicdatabase.
 134. The apparatus of claim 130, further comprising: a moduleto validate the source at location addresses.
 135. The apparatus ofclaim 134, wherein source validation is based on recognizing a taggingcode embedded in the source.
 136. The apparatus of claim 135, whereinthe tagging code is the unique, persistent, and universal nameidentifier.
 137. The apparatus of claim 135, wherein the tagging code isa security authorization mechanism.
 138. The apparatus of claim 137,wherein security authorization is provided to access the source. 139.The apparatus of claim 130, further comprising: a module to validatethat the source at location addresses is accessible.
 140. The apparatusof claim 130, further comprising: a module to provide statusnotification regarding validity.
 141. The apparatus of claim 140,wherein the status notification is regarding the validity of the unique,persistent, and universal name identifier.
 142. The apparatus of claim140, wherein the status notification is regarding the validity of thelocation addresses.
 143. The apparatus of claim 140, wherein the statusnotification is regarding the validity of the source.
 144. The apparatusof claim 140, wherein the status notification is in E-mail.
 145. Theapparatus of claim 140, wherein the status notification is provided to adelegated agent for error administration.
 146. The apparatus of claim140, wherein the status notification is governed by policies.
 147. Theapparatus of claim 146, wherein the policies specify escalatednotifications respective to escalated validity error status.
 148. Theapparatus of claim 130, wherein validating is achieved by pinging thelocation addresses.
 149. The apparatus of claim 148, wherein pingingincludes security authorization to facilitate access to secured sources.150. An apparatus for tagging a source, comprising: a processor; amemory, communicatively connected to the processor; a program, stored inthe memory, including, a module to determine a tagging code, wherein thetagging code, once recognized, establishes the validity of a source; amodule to tag a source with the tagging code, wherein the source isresolved to by a unique, persistent, and universal name identifier. 151.The apparatus of claim 150, further comprising: a module to validate thesource by recognizing the tagging code embedded in the source.
 152. Theapparatus of claim 151, wherein a triggering event causes validation.153. The apparatus of claim 150, further comprising: a module tovalidate that the location addresses are accessible.
 154. The apparatusof claim 150, wherein source tagging occurs during the registration of aunique, persistent, and universal name identifier.
 155. The apparatus ofclaim 150, wherein source tagging occurs during the creation of thesource.
 156. The apparatus of claim 150, wherein source tagging occurswithin a content authoring tool.
 157. The apparatus of claim 150,wherein the tagging code is the unique, persistent, and universal nameidentifier.
 158. The apparatus of claim 150, wherein the tagging code isa security authorization mechanism.
 159. An apparatus to effectregistration, comprising: a processor; a memory, communicativelyconnected to the processor; a program, stored in the memory, including,a module to determine a tagging code, wherein the tagging code, oncerecognized, establishes the validity of a source; a module to tag asource with the tagging code; a module to generate a unique, persistent,and universal name identifier associated with the source; a module toreceive an address for a location for the source; a module to effect theregistration of the unique, persistent, and universal name identifierwith the address associated to the location of the source in a databasefor resolving unique, persistent, and universal name identifiers andlocations of associated sources, wherein the unique, persistent, anduniversal name identifier is unique in the database.
 160. The apparatusof claim 159, wherein the tagging code is the unique, persistent, anduniversal name identifier.
 161. The apparatus of claim 159, wherein thetagging code is a security authorization mechanism.
 162. The apparatusof claim 159, further comprising: a module to validate that the locationaddresses are accessible.
 163. The apparatus of claim 162, wherein atriggering event causes validation.
 164. The apparatus of claim 159,further comprising: a module to validate the source by recognizing thetagging code embedded in the source.
 165. An apparatus to effectregistration, comprising: a processor; a memory, communicativelyconnected to the processor; a program, stored in the memory, including,a module to determine a tagging code, wherein the tagging code, oncerecognized, establishes the validity of a source; a module to tag asource with the tagging code; a module to allocate space in a storagefacility for the source; a module to make a location of the allocatedspace addressable and accessible over a communications network; a moduleto store the source to the allocated space; a module to generate aunique, persistent, and universal name identifier associated with thesource; a module to effect the registration of the unique, persistent,and universal name identifier with an address associated to the locationwhere the source is stored in a database for resolving unique,persistent, and universal name identifiers and locations of associatedsources, wherein the unique, persistent, and universal name identifieris unique in the database.
 166. The apparatus of claim 165, wherein thetagging code is the unique, persistent, and universal name identifier.167. The apparatus of claim 165, wherein the tagging code is a securityauthorization mechanism.
 168. The apparatus of claim 165, furthercomprising: a module to validate the source by recognizing the taggingcode embedded in the source.
 169. The apparatus of claim 168, wherein atriggering event causes validation.
 170. The apparatus of claim 165,further comprising: a module to validate that the location addresses areaccessible.
 171. (canceled)
 172. (canceled)
 173. An apparatuses forvalidating location addresses, comprising: a processor; a memory,communicatively connected to the processor; a program, stored in thememory including, a module to obtain a unique, persistent, and universalname identifier for a source; a module to obtain location addresses ofthe source for resolution with the unique, persistent, and universalname identifier; a module to validate that the location addresses areaccessible, and if not, to take corrective action.